Re: Device count (to be done with)

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

> > 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