[PATCHES 2.5] pcmcia: add struct pcmcia_device

[Russell King]

On Sat, Apr 19, 2003 at 04:39:50PM +0200, Dominik Brodowski wrote:
> On Sat, Apr 19, 2003 at 02:46:35PM +0100, Russell King wrote:
> > > +	    if (resources_available) {
> > > +		    /* gotta go */
> > > +		    ioctl_resources_count = -ioctl_resources_count;
> > 
> > I can see this going horribly wrong.  I'd much prefer that we didn't
> > guess what's going on, but used something which told us positively
> > what the status is.  If that means we need to add extra functions to
> > rsrc_mgr.c, then that's the right answer.
> 
> I disagree. There's no way rsrc_mgr.c can know whether the resource
> initialization is ongoing, done, or whether cardmgr is in the process of
> unloading (or, worse, resetting).

True, however, it is also wrong for some in-between level to try to
decant what state resources are in - it just isn't a sane solution.
cardmgr is not the only user of ds_ioctl(), and as such, you have
some race conditions there.

Let's say the user runs "watch cardctl ident" while sending a SIGHUP
to cardmgr.  How can we guarantee that we won't receive an ioctl from
cardctl rather than cardmgr?  I don't think we can, and when this
happens, ioctl_resources_count will become horribly unsynchronised
with the current state, both of the resource subsystem and cardmgr.
What's worse is, I don't believe you can recover from this without
rebooting (or reloading the pcmcia_core module if you're using modules.)

> Of course, it would be better if cardmgr told us about the state of the
> resources. Or, even better, if the whole resource management code was the
> way you want it to be :) But as long as this isn't done I want to keep near
> to 100% backwards-compatibility.

I think it's looking very much like we won't be able to achieve that with
this change - we desperately need cardmgr to give us more information.
When it does...

> > can suspend the insert processing if resources aren't available (via
> > your favourite method) and then call pcmcia_resources_available() to
> > cause the state machine to re-test the resource state.  (see my
> > socket map-type patch for an example of this.)
> 
> AFAICS this won't help. Even if by some state machine mechanism ds.c can
> learn that there are enough resources available for some things like CIS 
> parsing, it will be in a highly unreliable state: it won't know whether the
> whole resource setting process is done. (and this time, we need to take
> special care for non-statically mapped sockets!)

... we can use this extra information to suspend the state machine on
insert until it has completed its resource setup.  In the case of cardmgr
changing resources, the kernel pcmcia code would have to know when it
starts and finishes so that it knows when to reallocate the resources.

-- 
Russell King (rmk at arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html