From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Tue, 16 Oct 2001 07:02:22 +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 > > The should-count has a > > fundamentially different meaning than the use count (must-count). > > I am still not convinced that you need a separate count field, if > _either_ count is non-zero then the module will not be unloaded. A > single count is all that is required. 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. Those can't be handled with a single counter without removing a current OS function that's rather important: the ability to replace a driver without rebooting. The point of having a separate counter is to support the (new) policy that drivers are normally not removed so long as devices are present. > Adding a second count field will be very messy. ... Not very messy, though I agree with the comment that doing it in a compatible way is important ... though it should be easy enough to ensure that new modutils continue to work on old kernels, and I've never heard of a requirement that new kernels work with old modutilis (quite the opposite in fact). > The second count has to be exposed for rmmod and friends. This is the > biggest mess, struct module_info has to be expanded to hold the new > count, syscall query_module and several bits of modutils also have to > be changed for the new structure size. Adding one field to a data structure is easy, even if it needs to change in both the kernel and in modutils (sigh). There'd be a new "which" parameter to sys_query_module() to expose the QM_DEVS counter. Add a minor patch to modutils and it'll cope with the bigger structure without noticing the difference ... and teaching "rmmod" about testing a new field (unless there's an override flag passed in) is easy. What'd be more work is updating the user visible displays of this stuff. Someone documented that "lsmod" and /proc/modules give the same output, and I'm sure that programs parse that text. So either exposing that is a 2.5 thing or this information won't show up in those places, which will be a bit of a surprise. - 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