Re: Device count (to be done with)

[Keith Owens <kaos@ocs.com.au>]

On Mon, 15 Oct 2001 23:27:52 +0100, 
Stamatis Mitrofanis <ewstam@softhome.net> wrote:
>I'm not very sure about that one. We had a suggestion from Keith Owens 
>for a hidden /proc entry. I'll quote:

Not hidden, just root only.

>
>* kernel/module.c registers /proc/sys/kernel/mod_use_count, mode 600.
>* module.c creates a dummy module entry called mod_use_count the first
>  time that /proc/sys/kernel/mod_use_count is written to.
>* /proc/sys/kernel/mod_use_count recognises commands like
>    up module-name
>    down module-name
>  and adjusts the use counts and reference chain accordingly.  Hotplug
>  scripts use mod_use_count to bump the reference count before allowing
>  a start event to continue and after completing a stop event. "
>
>Now our point of disagreement is whether this file will be read-only or 
>it will also accept two commands (something like "inc" and "dec").

The file cannot be read only, it exists to take commands from user
space to adjust the use count on loaded modules.

echo "up foo" > /proc/sys/kernel/mod_use_count

increments the use count on module foo.  Whether the command is "up" or
"inc" is irrelevant.

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

Adding a second count field will be very messy.  It has to be stored
somewhere in the module header created by insmod so you need a new
version of insmod.  Alternatively it can be stored in an area created
by syscall init_module and pointed to by the kernel_data field, that
needs a new kernel.

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.

It is absolutely that such changes are backwards compatible.  Users can
run new modutils on old kernels and vice versa, some people even run
modutils 2.4 on 2.0 kernels.  I will not accept any change that breaks
compatibility between modutils and kernels at the moment.  modutils 2.5
will break compatibility all over the place but that is acceptable for
development modutils and kernels.

Since it is a lot of work to add a separate count field, you will have
to convince me that you really need a separate count.  Neither rmmod
nor autoclean (which is just rmmod -a) will remove any module with a
non-zero use count.  Either the "should" count stops unloading or it
does not.  If it does not stop rmmod then the "should" count is
pointless.


_______________________________________________
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