Re: udev sysfs docs Re: State of devfs in 2.6?

From: Jamie Lokier
Date: Fri Dec 12 2003 - 09:58:26 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/