Re: Device count (to be done with)

[Stamatis Mitrofanis <ewstam@softhome.net>]

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