Device count (to be done with)

DISCUSSION Stamatis Mitrofanis 6 participants 15 messages Oct 10, 2001 – Oct 16, 2001

Share & tools

Stamatis Mitrofanis

author

2001-10-10 20:06 UTC #0 lore raw

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Oliver Neukum

2001-10-11 15:01 UTC #1 lore raw

Quoted 4 lines

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

Stamatis Mitrofanis

author

2001-10-12 22:53 UTC #2 lore raw

In reply to Stamatis Mitrofanis

Quoted 9 lines · Oliver Neukum

Quoted 5 lines
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...)

Oliver Neukum

2001-10-13 08:45 UTC #3 lore raw

In reply to Stamatis Mitrofanis

Quoted 4 lines

Quoted 3 lines
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.

Quoted 8 lines

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

Stamatis Mitrofanis

author

2001-10-15 00:15 UTC #4 lore raw

In reply to Stamatis Mitrofanis

Quoted 11 lines · Oliver Neukum

Quoted 11 lines
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).

Quoted 9 lines

Quoted 2 lines
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...

[email protected]

2001-10-15 09:39 UTC #5 lore raw

In reply to Stamatis Mitrofanis

Quoted 3 lines · Stamatis Mitrofanis

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.

Quoted 2 lines

- when should-count is decremented to 0, the module is "autoclean".
- should-count is queried by kernel.

What for ?

Quoted 11 lines

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

Quoted 6 lines

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.

Quoted 2 lines

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

Stamatis Mitrofanis

author

2001-10-15 22:27 UTC #6 lore raw

In reply to Stamatis Mitrofanis

Quoted 32 lines · [email protected] wrote:

Quoted 4 lines · Stamatis Mitrofanis
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.
Quoted 3 lines
- when should-count is decremented to 0, the module is "autoclean".
- should-count is queried by kernel.
What for ?
Quoted 11 lines
- 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.
Quoted 7 lines
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.

Quoted 3 lines

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.

Quoted 8 lines

Quoted 3 lines
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.

Keith Owens

2001-10-16 04:03 UTC #7 lore raw

In reply to Stamatis Mitrofanis

Quoted 2 lines · Stamatis Mitrofanis

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.

Quoted 11 lines

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

Quoted 2 lines

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.

Quoted 2 lines

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.

Greg KH

2001-10-16 05:37 UTC #8 lore raw

In reply to Stamatis Mitrofanis

Quoted 4 lines · Keith Owens

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

Keith Owens

2001-10-16 05:59 UTC #9 lore raw

In reply to Stamatis Mitrofanis

Quoted 2 lines · Greg KH

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>

David Brownell

2001-10-16 07:02 UTC #10 lore raw

In reply to Stamatis Mitrofanis

Quoted 6 lines

Quoted 2 lines
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.

Quoted 1 line

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

Quoted 4 lines

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

Oliver Neukum

2001-10-16 08:23 UTC #11 lore raw

In reply to Stamatis Mitrofanis

Quoted 10 lines

Quoted 2 lines
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.

Quoted 6 lines

Quoted 2 lines
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.

Quoted 5 lines

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.

Quoted 11 lines

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.

Quoted 6 lines

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

Oliver Neukum

2001-10-16 08:29 UTC #12 lore raw

In reply to Stamatis Mitrofanis

Am Dienstag, 16. Oktober 2001 07:37 schrieben Sie:

Quoted 11 lines · Keith Owens

Quoted 3 lines
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

Keith Owens

2001-10-16 08:47 UTC #13 lore raw

In reply to Stamatis Mitrofanis

Quoted 7 lines · David Brownell

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.

Quoted 5 lines

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

Quoted 2 lines

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.

Oliver Neukum

2001-10-16 12:00 UTC #14 lore raw

In reply to Stamatis Mitrofanis

Quoted 3 lines

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

Quoted 5 lines

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

Quoted 3 lines

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

Quoted 7 lines

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

Quoted 6 lines

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

[..]

Quoted 6 lines

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.

Quoted 6 lines

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 ?

Quoted 9 lines

Quoted 2 lines
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