Re: Flaw in the driver-model implementation of attributes

From: Alan Stern (
Date: Wed Jun 18 2003 - 09:32:22 EST

On Wed, 18 Jun 2003 wrote:

> BS. There is nothing to stop you from having a block device that talks
> to userland process instead of any form of hardware. As the matter of
> fact, we already have such a beast - nbd. There is also RAID - where
> there fsck is 1:1 here? There's also such thing as RAID5 over partitions
> that sit on several disks - where do you see 1:1 or 1:n or n:1?
> There is such thing as e.g. encrypted loop over NFS. There are all
> sorts of interesting things, with all sorts of interesting relationship
> to some pieces of hardware.

This is the sort of thing that bothers me. Block devices deserve their
own "view", so we have /sys/block/ -- perhaps to be renamed
/sys/class/block/. Fine.

But what other sorts of things deserve their own "view" as well? Some
are already established, maybe others aren't. How's a developer supposed
to know whether the driver he's working on deserves its own entry in
/sys/class/ or not? How's a user supposed to know where in the hierarchy
to look for a particular device?

Here's a suggestion for something that would definitely help. Create a
listing (maybe in Documentation/driver-model/) of all the major kernel
subsystems that deserve to have their own entries in /sys/class/ (or the
equivalent). Explain clearly that any device driver that registers with
one of those subsystems will receive a directory in the /sys/class/
hierarchy where it can register its class devices, and say what the name
of that directory will be. Explain that a driver that doesn't register
with one of these subsystems will simply have to create its own entry in
/sys/devices/ under its parent node.

Not all this infrastructure has been created yet. For instance, there
isn't at the moment any place under /sys/class/usb/ for a USB host
controller driver to register its class device. But if these ideas were
formalized and written down, it would be straightforward to fill in the
missing pieces.

Alan Stern

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:24 EST