From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Owens Date: Tue, 16 Oct 2001 08:47:47 +0000 Subject: Re: Device count (to be done with) 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 On Tue, 16 Oct 2001 00:02:22 -0700, David Brownell wrote: >I'll have to repeat myself, then, until the point sticks or is refuted: >TWO POLICIES are needed: > > - One for normal operation, no sysadmin or developer involved. > That's the policy where both counts must be zero before it's > OK to unload. > > - Separately, a policy whereby sysadmins can ignore what > Stamatis has called the "should-count" (matching how many > drivers are using the device). Sysadmins (and developers) > need to be able to swap drivers, in cases where normal > operational safeguards don't apply. That can be handled fairly easily. * Add a separate count in the kernel, pointed to by the kernel_data field of the module header (this is why I added kernel_data). This count is the "should" count. * Report module use count as the sum of the existing use count plus the "should" count. No changes to syscall, modutils or proc interfaces :). * Kernel adds /proc/sys/kernel/modules/foo/should_count (needs a better name). echo "+1" > /proc/sys/kernel/modules/foo/should_count echo "-1" > /proc/sys/kernel/modules/foo/should_count cat /proc/sys/kernel/modules/foo/should_count reports existing count, for each module foo. * To remove the module, take the "should" count to 0. As long as the existing module use count is zero, you can unload the module. echo "0" > /proc/sys/kernel/modules/foo/should_count Does the sysadmin need to note the count before clearing it and reset the count after reloading? Probably not, hotplug events should set the count on reload. Do you realise that you are close to reinventing Rusty Russell's module redesign? 2.5 modules will have four module functions, instead of the current two. module_load() - grab hardware, can fail. module_register() - make module available to other code, cannot fail. module_unregister() - remove access from other code, can fail. module_unload() - free hardware, cannot fail. The normal 2.5 module life cycle is :- (1) Load. (2) Register. (3) rmmod, use count is 0. (4) Unregister. No new code can use the module, existing users who have just entered will run to completion. It is assumed that the module will notify these users that it is going away, e.g. return EOF. (5) Synchronize kernel. This flushes out any users who have entered the module but not yet left. They either leave or set MOD_INC_USE_COUNT. (6) Unload. There is a perennial race in module unloading: CPU 0 CPU 1 rmmod checks use count use count is 0 syscall delete_module use count is still 0 module is still registered, user enters the module module unregisters use count is still 0 MOD_INC_USE_COUNT unload module Oops The 2.5 redesign removes this race. It will ensure that a module is not removed until it is guaranteed that no user is running anywhere in the module code. In the race above, the life cycle would be :- (1) Load. (2) Register. (3) rmmod, use count is 0. (4) User enters module on cpu 1. (5) Unregister on cpu 0. (6) User does MOD_INC_USE_COUNT on cpu 1. (7) Synchronize kernel. (8) Use count is now 1, rmmod lost the race, go back to (2). There is a nice side effect of separating hardware and software module functions. You will be able to say "rmmod -f" to force a module unload. That will go :- (1) Load. (2) Register. (3) rmmod -f, ignore use count. (4) Unregister. (5) Synchronize kernel. (6) Wait for use count to go to 0. (7) Unload. Modules can define their own functions to decide if they can be unloaded or not. A module that does this shows up with a use count of -1, rmmod does not check the use count, instead it calls the module's can_unload() function. can_unload() does whatever the module wants, including checking other counts. You can already do this on 2.4. The problem with 2.4 is that there is no way to pass a flag to syscall delete_module() so the module cannot tell the difference between rmmod, rmmod -a and rmmod -f. Rusty and I need to sort this out for 2.5. With the above design and the ability to pass flags to delete_module(), you probably do not need /proc/sys/kernel/modules/foo/should_count. The module decides if it can be unloaded or not. >I've never heard of a requirement that new kernels work with old >modutilis (quite the opposite in fact). Some users don't read Documentation/Changes and run old modutils on new kernels. I even have to worry about the idiots who run modutils 2.1.121 on 2.4 kernels :(. They do not get the full functionality of the new modutils but they must not crash either. That is, old modutils on new kernels must be fail safe, I cannot make any incompatible interface changes in stable kernels or utilities. 2.5 will break modules all over the place, as long as I get my changes in early enough to let distributions ship the correct utilities. _______________________________________________ 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