From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stamatis Mitrofanis Date: Mon, 15 Oct 2001 22:27:52 +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 Oliver.Neukum@lrz.uni-muenchen.de wrote: >On Mon, 15 Oct 2001, Stamatis Mitrofanis wrote: > >>If I got your idea right, you suggest that: >>- should-count is stored for each kernel module, independent of >>"subsystem" (usb, pci etc.). >> >Yes, but the subsystem might very well manage the count on behalf of >individual modules. > >>- when should-count is decremented to 0, the module is "autoclean". >>- should-count is queried by kernel. >> >What for ? > >>- should-count is incremented/decremented by kernel. >>- should-count is queried by modprobe. >> >>I was suggesting the following: >>- should-count is stored for each kernel module, independent of "subsystem". >>- when should-count is decremented to 0, the module is "autoclean". >>- should-count is queried by kernel. >>- should-count is incremented/decremented by kernel. >>- should-count is queried by modprobe. >>- should-count is incremented/decremented by modprobe. >> >>It's just whether user-space is allowed to increment/decrement the count >>that differs. I believe that there has to be a user-space interface to >>this count since the should-count is abstract (hence not specific to >>PCI, USB or anything) and counts just "reasons for this module to remain >>loaded (not to be autocleaned)" . Thus, user-space may have its own set >>of reasons to have this module loaded in the kernel. >> >If user space wants that it should implement its own counters or locking >scheme. > If you're concerned about robustness then I don't think there's any problem in allowing user-space to "order" the kernel to increment/decrement the "should-count". Tell me what you don't like. >>I think we've pretty much settled this issue. So now, the question is >>(again), who's going to write it... >> >I will do it unless someone volunteers until next week, when I'll have the >time necessary. >Question, by which mechanism should user space be able to query the count >? > I'm not very sure about that one. We had a suggestion from Keith Owens for a hidden /proc entry. I'll quote: "Without knowing exactly what you are trying to do I am guessing but it sounds like you need this: * 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. " He even offered to implement it. Of course, at that time he was referring only to the "use count" (not a separate count), but it sounds good for the should-count. 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"). Let me reiterate that user-mode programs/scipts must only access the count via modprobe (that was what modprobe was built for in the first place). But I still don't think that modprobe must have its own locking mechanism because it would not be uniform. The should-count has a fundamentially different meaning than the use count (must-count). The module can be unloaded anytime safely (unless of course the _use count_ is nonzero). It only says whether "it is convenient for the user that the module is loaded" (whether it "should" remain loaded, as opposed to whether it "must" remain loaded). So it is acceptable for user-space to be able to handle it. _______________________________________________ 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