Re: Flaw in the driver-model implementation of attributes

Alan Stern (stern@rowland.harvard.edu)
Wed, 18 Jun 2003 10:32:22 -0400 (EDT)


On Wed, 18 Jun 2003 viro@parcelfarce.linux.theplanet.co.uk 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 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/