From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Fri, 05 Oct 2001 08:53:05 +0000 Subject: Re: Unloading drivers, start-up, shut-down and a rewrite (a problem) 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 Hi Keith, > I am not convinced that we need a separate count, at least not at the > bottom layer. The module use count is a pure reference count on the > module code, rmmod does not care what the types of reference are, rmmod > just cares if it is safe to unload the code. While "rmmod" may not care, there are two distinct user communities that IMO need to be supported: - "real users", 95+% of the computer users in the world, who want things to "just work" and never need root access or a sysadmin; - "sysadmin" or "developer" ... who does troubleshooting/upgrading/... and so needs extra system capabilities. I think "one use count" might work for a "real user", but not for anyone who wants safe ways to replace drivers on running systems. If there's just one use count, adjusted in userland, it'd be too easy for userland bugs to corrupt things. (What do you mean by "need"? :) > >Likely "rmmod" needs a flag that says whether the device count is > >ignored, as (effectively) done today. Driver developers will want the > >flexibility to say "remove this driver even though there's hardware > >attached, I've got a bugfix". USB developers work in that mode > >today, it's quite handy. > > See above, I don't see any need to distinguish between references. How would someone SSH into a system and upgrade some of its drivers? With two counts, one can shutdown all code using the drivers (use count goes to zero), then say "ignore any hardware, just remove the driver". And then start things up again; perfectly safe, even a sleep-deprived and seriously aggravated sysadmin can't make mistakes (run some command too many times :) and thereby crash the server (consequences left to your imagination). > If the device is up then the module cannot be unloaded. That does assume > that all devices can be deactivated which is not currently true, to do > this properly every device driver would need an up and a down routine. If "up" is a software notion, that's what I see the current use count as being used for. (I can't see it being a hardware notion...) But I'm not sure what you're saying "is not currently true". Hotpluggable drivers get told when the hardware comes and goes, by USB or PCI etc. With USB, that doesn't modify any use counter, ensuring that drivers can safely be reloaded so long as they're not actually in use. If the hardware is accessed through the file system device nodes, open/release routines apply; network drivers have up/down analogues. Those all (should) update the current use count, keeping the driver from being unloaded until the device becomes inactive. > I can add a use count up/down interface to kernel/module.c without > waiting for every driver to be converted to an up/down interface. The same with MOD_{INC,DEC}_DEV_COUNT() support; it's not drivers that'd need converting, but subsystems. Two lines (each) in the right places of usb.c, pci.c (or wherever). Changing every single driver would be wrong, I'd agree. > However we have to agree on a common design for drivers, I would hate > to see some modules supporting up/down and others doing it a different > way. We have USB pretty well in hand, as I described above. It could again serve as a guinea pig ... :) - Dave _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel