Re: Adding PCMCIA support to the kernel tree -- developers needed.

[David Brownell <david-b@pacbell.net>]

> From: "Keith Owens" <kaos@ocs.com.au>
>
> FWIW there has been some discussion between kernel developers about
> redesigning the module load/unload mechanism.  Rusty Russell points out
> that controlling module use counts by exporting the module structure
> via the owner field does not work when the use count needs to be
> manipulated from an interrupt.  In Rusty's case he is thinking about
> netfilter, but the same point applies to hot unplugging.

I'm not sure I'd want module "use" count to be affected by plugging and
unplugging, but I'd like to have that kind of way to track the number of
devices associated with a module!  Normal users won't expect to see
devices become unusable (by driver removal) except by disconnecting,
for all that developers should still be able to hotswap the drivers that
aren't actively using the device.


> Current thinking is to change modules so they have four required
> functions, instead of the current two functions.
> 
>   init: Allocate resources.
>   register: Make services available.
>   unregister: Remove services.
>   exit: Deallocate resources.

I'll have to think on this a bit ... seems initially plausible, but it'll need
to fit neatly with suspend/resume and probe/disconnect processing
and I'll want to think about that.  All of those involve managing some
sort of resource or service.  I can't think of many resources/services
that really ought to be managed at the _module_ level rather than at
the granularity of individual devices ... except for modules that don't
hold device drivers, maybe!


> I think this will help hot unplugging.  When the device disappears, the
> driver internally marks its hardware as unusable and schedules an
> unconditional shutdown of itself, all out of the interrupt handler.

Maybe it won't be detected in_irq() though.  For example, USB device
drivers typically have their disconnect() routines called by real threads.
("khubd", except for root hubs.)

Also, there's the issue that modules can manage multiple devices.
Just because someone unplugged one <foo> adapter doesn't mean
the others should get brought down and the driver removed!!


> Unconditional shutdown calls unregister which stops any new code
> entering the module.  

Then clearly it should not be used with hot-unplug, since driver modules
are typically expected to handle multiple similar devices.  Unplug of one
mustn't affect the others.


>    The driver returns -EIO for all outstanding
> requests which will eventually result in the outstanding users calling
> close() or its equivalent and leaving the module.  When the use count
> finally goes to zero, exit releases the resources and the module is
> removed.  

Until that last "module is removed", it sounded like a reasonable
description of what a usb or pci disconnect() routine has to cause
when it's told that a device has gone away.


>    For built in code we do almost the same, the only difference
> is that built in code is not removed from memory.

I'd like to see that be "built-in modules or ones still coupled to
some connected device" ... so that when the last device owned
by the module goes away, it becomes eligible for removal.


- Dave




_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel