Re: Device count (to be done with)

[Oliver Neukum <Oliver.Neukum@lrz.uni-muenchen.de>]

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

We are not yet in agreement whether user space needs to be able to change the 
count.

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

No the modules with the "should" count nonzero should be unloadable. Only 
autoclean should not unload them.
The meaning of the current use count should not be altered.

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

We need a new kernel anyway as the older kernels will not increment and 
decrement the new counter.

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

This is 2.5 stuff.

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

It should stop just autoclean.
The issue is that USB drivers for devices connected to a computer can be 
unloaded when the device is not opened. Though obviously the device becomes 
thus unusable. Therefore autoclean cannot be used with USB drivers.
Additionally we cannot unload the module on the hotplug device removal event, 
as the module may be needed for several devices, only one of which is removed.
A counter is needed. Doing it in kernel space is robuster as finding out 
which drivers are bound to which devices at removal time is messy.

	Regards
		Oliver

_______________________________________________
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