(remove) event not supported.
Quoted 4 lines
Mar 30 08:07:01 localhost /etc/hotplug/usb.agent: USB remove event not supportedWhat are the issues associated with it. Is this something that just hasn't been coded up or is it something that can't be coded up.
Awkward to code up. What one really wants to happen is have the device's module removed ... and _maybe_ some driver-specific action (not that I can think of any examples just now). But:
- the dynamic linking framework doesn't track how many devices are attached to each driver module ... so if there's another device controlled by the same driver, but it's not opened, removing that module would be incorrect. ("module use count" doesn't cover uses, just opens.)
- nothing's tracking which modules are used with which device, and if the device is gone you can't query it to find that out!
Such issues aren't specific to USB; any hotpluggable bus has such problems. But it's worst for USB: PCMCIA and Cardbus tend to only have one device of a type at a time, and typically only have two slots, but USB can handle a hundred devices, and it's not that uncommon to have multiple devices.
Quoted 2 lines
If it simply hasn't been written, if you give me a few pointers on how it should be written. I'll code it up.
I think that it'll be tough to provide a "good" fix for this without updating the module framework; and that maybe a few other issues will show up too. But maybe there are better ways to look at this problem.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines · David Brownell
Quoted 5 lines
Mar 30 08:07:01 localhost /etc/hotplug/usb.agent: USB remove event not supportedWhat are the issues associated with it. Is this something that just hasn't been coded up or is it something that can't be coded up.
Awkward to code up. What one really wants to happen is have the device's module removed ... and _maybe_ some driver-specific action (not that I can think of any examples just now). But:
umounting a storage device? Or does that happen automatically? I am not going to pull out a mounted zip drive to find out...
Quoted 5 lines
- the dynamic linking framework doesn't track how many devices are attached to each driver module ... so if there's another device controlled by the same driver, but it's not opened, removing that module would be incorrect. ("module use count" doesn't cover uses, just opens.)
This could be trivially extended to have a inc_dev_open_count() and inc_dev_use_count(), where the use count get incremented in probe() and the open count gets incremented in open(). Naturally you also have to have a dec version of each as well, in disconnect() and close().
Quoted 2 lines
- nothing's tracking which modules are used with which device, and if the device is gone you can't query it to find that out!
maybe the driver could have a list of devices? not so easy to implement though.
Brad
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines · Brad Hards
Quoted 5 lines · David Brownell
- the dynamic linking framework doesn't track how many devices are attached to each driver module ... so if there's another device controlled by the same driver, but it's not opened, removing that module would be incorrect. ("module use count" doesn't cover uses, just opens.)
This could be trivially extended to have a
inc_dev_open_count()andinc_dev_use_count(), where the use count get incremented inprobe()and the open count gets incremented inopen(). Naturally you also have to have a dec version of each as well, indisconnect()andclose().
AFAICT there is no need for another count, you can do MOD_INC_USE_COUNT in any module function. The use count does not have to be for just open. Add MOD_INC_USE_COUNT to the probe() function for each new device.
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 15 lines · Keith Owens
Quoted 11 lines · Brad Hards
Quoted 5 lines · David Brownell
- the dynamic linking framework doesn't track how many devices are attached to each driver module ... so if there's another device controlled by the same driver, but it's not opened, removing that module would be incorrect. ("module use count" doesn't cover uses, just opens.)
This could be trivially extended to have a
inc_dev_open_count()andinc_dev_use_count(), where the use count get incremented inprobe()and the open count gets incremented inopen(). Naturally you also have to have a dec version of each as well, indisconnect()andclose().
Quoted 4 lines
AFAICT there is no need for another count, you can do
MOD_INC_USE_COUNTin any module function. The use count does not have to be for just open. AddMOD_INC_USE_COUNTto theprobe()function for each new device.
An excellent point. I shouldn't write before the first cup of Russian Caravan
in the morning.
Has anyone audited the drivers to see how consistently this is done?
Brad
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · Keith Owens
AFAICT there is no need for another count, you can do
MOD_INC_USE_COUNTin any module function. The use count does not have to be for just open. AddMOD_INC_USE_COUNTto theprobe()function for each new device.
So what if I want to unload a module for a device that still exists? These counts are also used in this way for non-hot-plugged devices.
For PCMCIA, device counts for each driver are published in /proc/bus/pccard/drivers, and cardmgr uses this information to help decide when to unload drivers.
-- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · David Hinds
Quoted 5 lines · Keith Owens
AFAICT there is no need for another count, you can do
MOD_INC_USE_COUNTin any module function. The use count does not have to be for just open. AddMOD_INC_USE_COUNTto theprobe()function for each new device.
Quoted 6 lines
So what if I want to unload a module for a device that still exists? These counts are also used in this way for non-hot-plugged devices.
For PCMCIA, device counts for each driver are published in
/proc/bus/pccard/drivers, and cardmgr uses this information to help decide when to unload drivers.
Also a good point, but in general, you don't want to do this. If there is a device still "connected" to the system, you don't want to remove the driver. For development, you might like to simulate a disconnection, but the normal approach is that you want support for every device that is connected to the system. Why remove a module for a device you are using?
It might be appropriate to remove the module (simulating the disconnect) on some other basis, like that it is close()'d, but I am not sure exactly what makes sense here.
Brad
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines
Quoted 5 lines
AFAICT there is no need for another count, you can do
MOD_INC_USE_COUNT
in any module function. The use count does not have to be for just open. AddMOD_INC_USE_COUNTto theprobe()function
for each new device.So what if I want to unload a module for a device that still exists? These counts are also used in this way for non-hot-plugged devices.
It's important to have the same policy for MOD_INC_USE_COUNT in all drivers. Including drivers, like network drivers, where the use count updating is automated ... both for hotpluggable drivers, and for the other kind.
Quoted 3 lines
For PCMCIA, device counts for each driver are published in
/proc/bus/pccard/drivers, and cardmgr uses this information to help decide when to unload drivers.
I suppose USB could add a third field to /proc/bus/usb/drivers; and PCI could add a /proc/bus/pci/drivers file too. It'd work.
Maybe those could be argued as 2.4 features; but going that way doesn't seem like the right general direction. It's clearly a generic facility that all hotpluggable drivers need, which in my book means it's best to do it only once.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Mar 30 08:07:01 localhost /etc/hotplug/usb.agent: USB remove event not supportedWhat are the issues associated with it. Is this something that just hasn't been coded up or is it something that can't be coded up.
Quoted 6 lines
Quoted 3 lines
Awkward to code up. What one really wants to happen is have the device's module removed ... and _maybe_ some driver-specific action (not that I can think of any examples just now). But:
umounting a storage device? Or does that happen automatically? I am not going to pull out a mounted zip drive to find out...
There we go, the example I knew was lurking! Likewise shutting down printer queues.
Quoted 11 lines
Quoted 5 lines
- the dynamic linking framework doesn't track how many devices are attached to each driver module ... so if there's another device controlled by the same driver, but it's not opened, removing that module would be incorrect. ("module use count" doesn't cover uses, just opens.)
This could be trivially extended to have a
inc_dev_open_count()andinc_dev_use_count(), where the use count get incremented inprobe()and the open count gets incremented inopen(). Naturally you also have to have a dec version of each as well, indisconnect()andclose().
I'd hate to change the semantics of the "use" count (which is really used as "open" count) ... but yes, adding another "driver count" is conceptually straightforward. Packaging it (and documenting it) would likely be a 2.5 issue.
Quoted 5 lines
Quoted 2 lines
- nothing's tracking which modules are used with which device, and if the device is gone you can't query it to find that out!
maybe the driver could have a list of devices? not so easy to implement though.
Most such drivers DO have a list of devices, but I shudder to think of updating each one to publish it in some idiosyncratic format somewhere in /proc ... best to fix this just once, for all drivers.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · David Brownell
I'd hate to change the semantics of the "use" count (which is really used as "open" count)
No, the module use count is a reference count on the module, not an open count. It correlates with the open count for many modules because it is usually incremented in the open() routine, but it can be incremented in any module function. Any code assuming that mod use count is the same as open files is broken.
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines
Quoted 2 lines
I'd hate to change the semantics of the "use" count (which is really used as "open" count)
No, the module use count is a reference count on the module, not an open count.
It's not a reference count, since it doesn't address the case where another module references it ... "rmmod" uses additional magic to handle such dependency cases. Since the counter can be (as you highlighted!) updated at any time, there's nothing to make it be a "reference" count. The networking framework is pretty explicit that it must be used as an "open" count (SET_MODULE_OWNER arranges this).
Perhaps the best way to describe this counter is that it's there, and "rmmod" won't remove modules where it's nonzero. (Or has never been nonzero...) Which doesn't seem to accomodate the needs of a hotplug-oriented world.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · David Brownell
It's not a reference count, since it doesn't address the case where another module references it
It is a dynamic reference count. The reference from another module is a static reference count. Historical.
Quoted 4 lines
Since the counter can be (as
you highlighted!) updated at any time, there's nothing to make it be a "reference" count. The networking framework is pretty explicit that it must be used as an "open" count
If networking framework says that then it is wrong.
Quoted 1 line
(
SET_MODULE_OWNERarranges this).
SET_MODULE_OWNER only exports the address of the module structure so external code can adjust the use count. Normally that is via the open routine, but file systems just do one MOD_INC_USE_COUNT in fs/super.c so it is a mount count, not an open count. Some netfilter modules want to count the number of packets controlled by that module, again not an open count.
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines
Quoted 2 lines
It's not a reference count, since it doesn't address the case where another module references it
It is a dynamic reference count. The reference from another module is a static reference count. Historical.
I see what you're saying, but that doesn't mean I'd then agree to call it a "reference" count!
Quoted 8 lines
Quoted 7 lines
Since the counter can be (as
you highlighted!) updated at any time, there's nothing to make it be a "reference" count.The networking framework is pretty explicit
that it must be used as an "open" count
Quoted 6 lines
If networking framework says that then it is wrong.
Quoted 1 line
(
SET_MODULE_OWNERarranges this).
SET_MODULE_OWNERonly exports the address of the module structure so external code can adjust the use count.
When the interface is opened or closed ... and a few other cases related to calling into the module. (Related point: I suspect the USB code should do the same when it probes drivers, to avoid those same races.)
From the perspective of a normal user, "lsmod" for net drivers shows use count 0 when no interface exposed by that driver is "up" (open).
Quoted 5 lines
Normally that is via the open
routine, but file systems just do oneMOD_INC_USE_COUNTinfs/super.cso it is a mount count, not an open count. Some netfilter modules want to count the number of packets controlled by that module, again not an open count.
I'd argue those are all logically equivalent to "open": dynamic behavior (as you noted) that needs to prevent "rmmod".
One hopes that opening a block device like /dev/sda1 with a user mode tool, rather than "mount", will prevent "rmmod"...
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · Brad Hards
Also a good point, but in general, you don't want to do this. If there is a device still "connected" to the system, you don't want to remove the driver. For development, you might like to simulate a disconnection, but the normal approach is that you want support for every device that is connected to the system. Why remove a module for a device you are using?
Why?
Well the capability was one of the original reasons for creating modules in the first place; they were not created for dynamic loading of drivers for hot plug devices.
It is not an issue of removing a module for a device you are using; you may want to remove a module for a device you are *not* using, whether or not that device still happens to be present (and it may not even be capable of removal).
-- dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · David Brownell
Maybe those could be argued as 2.4 features; but going that way doesn't seem like the right general direction. It's clearly a generic facility that all hotpluggable drivers need, which in my book means it's best to do it only once.
I argued this too but Linus has said he believes it should be a bus specific thing, rather than part of the generic hot plug facility.
-- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · David Brownell
I'd argue those are all logically equivalent to "open": dynamic behavior (as you noted) that needs to prevent "rmmod".
One hopes that opening a block device like
/dev/sda1with a user mode tool, rather than "mount", will prevent "rmmod"...
Yes.
Opening /dev/sda1 increases the usage count on the sd_mod.o module and the associated lower level adapter driver (e.g. aic7xxx.o). The SCSI mid-level (if it is a module) has its usage count bumped when any lower level adapter driver (e.g. aic7xxx.o) or upper level driver (sd_mod.o) registers itself.
Seen from the sd driver's POV, both mount and dd cause sd_open() to be called and thus have the same affect on usage counts.
Doug Gilbert
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · David Hinds
Quoted 5 lines · Brad Hards
Also a good point, but in general, you don't want to do this. If there is a device still "connected" to the system, you don't want to remove the driver. For development, you might like to simulate a disconnection, but the normal approach is that you want support for every device that is connected to the system. Why remove a module for a device you are using?
Quoted 5 lines
Why?
Well the capability was one of the original reasons for creating modules in the first place; they were not created for dynamic loading of drivers for hot plug devices.
What's cool about modules, is that you can support everything from the same sets of bootdisk or the same kernel: Compare that to the state of Slackware in 1995. Being able to add support by modules is important, unloading them to save a few kilobytes much less so.
Signature · 7 lines
Trond Eivind Glomsrød Red Hat, Inc. _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel