From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Mon, 05 Feb 2001 01:56:13 +0000 Subject: Re: Adding PCMCIA support to the kernel tree -- developers needed. Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org > From: "Keith Owens" > > 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 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