lkml.org 
[lkml]   [2003]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.087 / U:1.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site