[PATCHES 2.5] pcmcia: add struct pcmcia_device

[Dominik Brodowski]

On Sat, Apr 19, 2003 at 04:06:21PM +0100, Russell King wrote:
> 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.

The whole PCMCIA resource management doesn't seem to be a sane soultion
right now...

<skipping the race condition you explained to me -- indeed, the
resource_count is breakable.>

> 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.

... but if we decide to break userspace -- and this is what you suggest, in
fact, a "compatibility mode" doesn't count :) -- we might want to break it 
once and forever wrt adding/removing available resources. This includes but
is not limited to not using ioctls but sysfs interfaces. But how should it
work? Pavel's suggestion of last Wednesday comes to my mind... copying it to
this place now:

On Wed, Apr 16, 2003 at 04:45:46PM -0400, Pavel Roskin wrote:
> 1) Card driver determines that the card needs e.g. 2Mb of memory
> (4k-aligned) and 0x40 bytes of I/O space starting at 0xXXXX0300.  The
> card formulates requests where all those requirements are represented in
> some way.
> 
> 2) pcmcia_core redirects the requests to the socket driver.
> 
> 3) Socket driver (and not pcmcia_core!) determines whether the hardware
> can provide the windows of the required size and with required alignment.
> SS_CAP_STATIC_MAP and io_offset should be obsoleted.
> 
> 4) Socket driver requests the necessary resources from the kernel resource
> pool.  Successful request locks the resource immediately.
> 
> 5) Socket driver programs the hardware to decode addresses in the
> allocated range.
> 
> 6) Card driver starts using the new memory and I/O windows.

	Dominik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-pcmcia/attachments/20030419/3caa3716/attachment.bin