From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Owens Date: Tue, 16 Oct 2001 04:03:23 +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 On Mon, 15 Oct 2001 23:27:52 +0100, Stamatis Mitrofanis 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