Device count (to be done with)

Device count (to be done with)

[Stamatis Mitrofanis]

I think it should be pretty obvious by now that we need a separate count 
for devices. To clarify things, the two counts are:
1. The classical "use" count, which (together with other things) counts 
"reasons that this module MUST remain loaded".
2. The new "convenience" count which counts "reasons that this module 
SHOULD remain loaded".

The "should" count should be mostly managed from userspace (but also 
give the option for modules to change it) and user space programs must 
not care about anything beyond modprobe. For uniformity, better put this 
"should" count right next to the "must" (use) count.


_______________________________________________
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

Re: Device count (to be done with)

[Oliver Neukum]

> The "should" count should be mostly managed from userspace (but also
> give the option for modules to change it) and user space programs must
> not care about anything beyond modprobe. For uniformity, better put this
> "should" count right next to the "must" (use) count.

Here I must disagree. You need to add more code to the kernel to return 
information on successfully binding drivers to devices to user space than by 
simply handling the counter.

	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

Re: Device count (to be done with)

[Stamatis Mitrofanis]

Oliver Neukum wrote:

>>The "should" count should be mostly managed from userspace (but also
>>give the option for modules to change it) and user space programs must
>>not care about anything beyond modprobe. For uniformity, better put this
>>"should" count right next to the "must" (use) count.
>>
>Here I must disagree. You need to add more code to the kernel to return 
>information on successfully binding drivers to devices to user space than by 
>simply handling the counter.
>
Of course, I understand that this system must be as robust as possible, 
but I was viewing things from the most global perspective. I mean I was 
only referring to "kernel modules" rather than devices. My thoughts were 
as simple as "two module loads will result in the module actually being 
uloaded only after two module unloads". I was just referring to module 
"convenience" counts which would be very useful (even necessary) to 
have. Now, if there need to be subsystem-specific error-handling 
mechanisms that's fine (the agent scripts can very well work with this).

Though a problem is that I'm surely not the most "qualified" person to 
make a patch for it since I'm not familiar with the kernel's insides (it 
would take me too long). I'd be very satisfied to hear that somebody is 
working on it.

(sorry for mentioning this over and over again but...)


_______________________________________________
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

Re: Device count (to be done with)

[Oliver Neukum]

> >Here I must disagree. You need to add more code to the kernel to return
> >information on successfully binding drivers to devices to user space than
> > by simply handling the counter.
>
> Of course, I understand that this system must be as robust as possible,
> but I was viewing things from the most global perspective. I mean I was
> only referring to "kernel modules" rather than devices. My thoughts were
> as simple as "two module loads will result in the module actually being
> uloaded only after two module unloads". I was just referring to module
> "convenience" counts which would be very useful (even necessary) to
> have. Now, if there need to be subsystem-specific error-handling
> mechanisms that's fine (the agent scripts can very well work with this).

There's no need. The module counter infrastructure is already there.
Another counter to be incremented on a further device addition is the 
simplest solution.

	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

Re: Device count (to be done with)

[Stamatis Mitrofanis]

Oliver Neukum wrote:

>>The reason for all this fuss is that the hotplug scripts be able to
>>properly _un_load modules as well as loading them. Just consider what
>>happens when you have two USB HID mice and you unplug one of them. The
>>driver gets unloaded while it shouldn't (the other mouse is still in).
>>
>>I just noted that a very simple way to do this is to add a new
>>"should-count" in the module loading/unloading mechanism and extend
>>modprobe a bit to support it. That ought to be a very simple change.
>>Also, it is not really necessary for the kernel modules themselves to
>>support playing with this count (but it would be a good thing though).
>>
>>I hope I'm not missing anything. Please give me more details.
>>
>There should be indeed a second counter.
>However you would not want it in the module load and unload path. To make 
>sense it has to be incremented on device detection and decremented on device 
>removal. All you need now is to make it queryable from user space to let 
>modprobe check.
>For USB you increment on successful probe() and decrement on disconnect()
>
Apparently, we have two very similar proposals... :-)

If I got your idea right, you suggest that:
- should-count is stored for each kernel module, independent of 
"subsystem" (usb, pci etc.).
- 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.

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.

I think we've pretty much settled this issue. So now, the question is 
(again), who's going to write 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

Re: Device count (to be done with)

[Oliver.Neukum]

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.

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

	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

Re: Device count (to be done with)

[Stamatis Mitrofanis]

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

Re: Device count (to be done with)

[Keith Owens]

On Mon, 15 Oct 2001 23:27:52 +0100, 
Stamatis Mitrofanis <ewstam@softhome.net> 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

Re: Device count (to be done with)

[Greg KH]

On Tue, Oct 16, 2001 at 02:03:23PM +1000, Keith Owens wrote:
> 
> 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.

I agree, I think the current module count is just fine.  

Again, what is the problem that you are trying to solve here?
The fact that when a device is removed, the driver is unloaded?
Is that a good goal?  And if so, why?  And why can't the current counter
be used for just that reason?

Right now there is a history of only incrementing the module usage
count when a userspace program opens a file through the driver.  That
can _easily_ be changed to increment and decrement when the device is
seen, and removed respectively, for hotpluggable devices.  The only ones
who will be inconvenienced would be the developers, hence the present
situation :)

thanks,

greg k-h

_______________________________________________
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

Re: Device count (to be done with)

[Keith Owens]

On Mon, 15 Oct 2001 22:37:32 -0700, 
Greg KH <greg@kroah.com> wrote:
>Right now there is a history of only incrementing the module usage
>count when a userspace program opens a file through the driver.

<nitpick>
The module use count has *NEVER* been defined as an open count, it is a
reference count that sometimes is the same as the count of open files.

Too many developers have made the mistake of assuming that use count =
open count.  For some modules the use count reflects the number of data
packets, others count the number of device commands in flight, others
just set the count to 1 and maintain their own data structures, only
setting the use count to 0 when all their data structures are free.
</nitpick>


_______________________________________________
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

Re: Device count (to be done with)

[David Brownell]

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

I'll have to repeat myself, then, until the point sticks or is refuted:
TWO POLICIES are needed:

    - One for normal operation, no sysadmin or developer involved.
       That's the policy where both counts must be zero before it's
       OK to unload.

    - Separately, a policy whereby sysadmins can ignore what
      Stamatis has called the "should-count" (matching how many
      drivers are using the device).  Sysadmins (and developers)
      need to be able to swap drivers, in cases where normal
      operational safeguards don't apply.

Those can't be handled with a single counter without removing
a current OS function that's rather important:  the ability to
replace a driver without rebooting.  The point of having a
separate counter is to support the (new) policy that drivers
are normally not removed so long as devices are present.


> Adding a second count field will be very messy.  ...

Not very messy, though I agree with the comment that doing it in
a compatible way is important ... though it should be easy enough
to ensure that new modutils continue to work on old kernels, and
I've never heard of a requirement that new kernels work with old
modutilis (quite the opposite in fact). 


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

Adding one field to a data structure is easy, even if it needs to change
in both the kernel and in modutils (sigh).  There'd be a new "which"
parameter to sys_query_module() to expose the QM_DEVS counter.
Add a minor patch to modutils and it'll cope with the bigger structure
without noticing the difference ... and teaching "rmmod" about testing
a new field (unless there's an override flag passed in) is easy.

What'd be more work is updating the user visible displays of this
stuff.  Someone documented that "lsmod" and /proc/modules give
the same output, and I'm sure that programs parse that text.  So
either exposing that is a 2.5 thing or this information won't show
up in those places, which will be a bit of a surprise.

- Dave



_______________________________________________
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

Re: Device count (to be done with)

[Oliver Neukum]

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

Re: Device count (to be done with)

[Oliver Neukum]

Am Dienstag, 16. Oktober 2001 07:37 schrieben Sie:
> On Tue, Oct 16, 2001 at 02:03:23PM +1000, Keith Owens wrote:
> > 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.
>
> I agree, I think the current module count is just fine.
>
> Again, what is the problem that you are trying to solve here?
> The fact that when a device is removed, the driver is unloaded?
> Is that a good goal?  And if so, why?  And why can't the current counter
> be used for just that reason?

Because it would prevent you from unloading modules that could perfectly well 
be unloaded, just like other modules can be.
Some drivers are quite large, eg pwc.

	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

Re: Device count (to be done with)

[Keith Owens]

On Tue, 16 Oct 2001 00:02:22 -0700, 
David Brownell <david-b@pacbell.net> wrote:
>I'll have to repeat myself, then, until the point sticks or is refuted:
>TWO POLICIES are needed:
>
>    - One for normal operation, no sysadmin or developer involved.
>       That's the policy where both counts must be zero before it's
>       OK to unload.
>
>    - Separately, a policy whereby sysadmins can ignore what
>      Stamatis has called the "should-count" (matching how many
>      drivers are using the device).  Sysadmins (and developers)
>      need to be able to swap drivers, in cases where normal
>      operational safeguards don't apply.

That can be handled fairly easily.

* Add a separate count in the kernel, pointed to by the kernel_data
  field of the module header (this is why I added kernel_data).  This
  count is the "should" count.

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

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

* 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

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.

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

  (1) Load.
  (2) Register.
  (3) rmmod, use count is 0.
  (4) Unregister.  No new code can use the module, existing users who
      have just entered will run to completion.  It is assumed that the
      module will notify these users that it is going away, e.g.
      return EOF.
  (5) Synchronize kernel.  This flushes out any users who have entered
      the module but not yet left.  They either leave or set
      MOD_INC_USE_COUNT.
  (6) Unload.

There is a perennial race in module unloading:

  CPU 0                                 CPU 1
  rmmod checks use count
  use count is 0
  syscall delete_module
  use count is still 0
					module is still registered, user
					enters the module
  module unregisters
  use count is still 0
					MOD_INC_USE_COUNT
  unload module
					Oops

The 2.5 redesign removes this race.  It will ensure that a module is
not removed until it is guaranteed that no user is running anywhere in
the module code.  In the race above, the life cycle would be :-

  (1) Load.
  (2) Register.
  (3) rmmod, use count is 0.
  (4) User enters module on cpu 1.
  (5) Unregister on cpu 0.
  (6) User does MOD_INC_USE_COUNT on cpu 1.
  (7) Synchronize kernel.
  (8) Use count is now 1, rmmod lost the race, go back to (2).

There is a nice side effect of separating hardware and software module
functions.  You will be able to say "rmmod -f" to force a module
unload.  That will go :-

  (1) Load.
  (2) Register.
  (3) rmmod -f, ignore use count.
  (4) Unregister.
  (5) Synchronize kernel.
  (6) Wait for use count to go to 0.
  (7) Unload.

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.

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

2.5 will break modules all over the place, as long as I get my changes
in early enough to let distributions ship the correct utilities.


_______________________________________________
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

Re: Device count (to be done with)

[Oliver Neukum]

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