Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 12 Dec 2003 14:51:24 +0000 | From | Jamie Lokier <> | Subject | Re: udev sysfs docs Re: State of devfs in 2.6? |
| |
Duncan Sands wrote: > > 2. Keep track of when devices are used, and when they are not busy. > > We already have this, it's the module reference count. > > USB modules (eg: xxxx-hcd) are typically set up so they can be > unloaded at any time: the act of unloading disconnects any devices > driven by the module and frees resources. I guess this is > problematic for your point 2. I understand that some network > modules work this way too.
I don't see a problem. A HCD device such as a keyboard is always "active" because it must always be listening for keys as long as the keyboard is plugged in. You can explicitly "soft unplug" by unloading the module; the proposal doesn't change that. (Although it would be a nice interface to copy the PCMCIA method, where you tell the USB subsystem to disconnect a device instead of having to know which module(s) to unload).
I agree that in that case, the device is active regardless of its module reference count. They aren't the same thing.
(Taking it further, USB keyboard is an example of a driver that could be made permanently demand-pageable as all of the code _could_ be executed in a process context, if USB's callbacks were made to work that way, but that road is potentially quite a complicated and error prone one).
A network device is similar as long as its interface is up (if it's a device). A protocol module is active as long as it has any active users, for which various definitions are possible.
Protocol (+ mid-layer, helper modules etc.) show that ideally the "active" property of a module includes any references to it by other active modules, which can be interpreted in a simple or a complicated way, depending on how thoroughly you want modules to be paged out while still presenting their interfaces in /sys, /dev, /proc, ifconfig, iptables etc.
-- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |