> 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
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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/