Re: Device count (to be done with)

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

> * Report module use count as the sum of the existing use count plus the
>   "should" count.  No changes to syscall, modutils or proc interfaces :).

That is a very good idea.

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

Do we really need these ?

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

Why would that be necessary ?
Can't we simply check the existing count and base the permission to unload on 
that ?

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

IMHO this shows that our ideas are sound ;-)

>  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 :-
[..]
> 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.

This would work, but force us to repeat code fairly often, as all 
hotpluggable devices share this problem. Could the 2.5 generic code check the 
"should count", if the flag for -a is set ?

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

This is wise and we should wait for 2.5. Let's hope it'll be soon now.

	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