Messages in this thread | | | Date | Wed, 18 Jun 2003 10:32:22 -0400 (EDT) | From | Alan Stern <> | Subject | Re: Flaw in the driver-model implementation of attributes |
| |
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/
| |