Re: Flaw in the driver-model implementation of attributes
Wed, 18 Jun 2003 09:12:28 +0100

On Wed, Jun 18, 2003 at 12:48:59AM -0700, Perez-Gonzalez, Inaky wrote:

> [I happen not to know the block layer as well as you and many others
> do, so please correct me where I am wrong ...]
> So what? _every_ block device will have some form of physical
> back-up that can be linked back into sysfs.

... except ones that will not. Wonderful. I bow to that logics - there
is nothing it wouldn't cover.

> In cases like this, doesn't it make sense to have some
> /sys/devices/SOMETHING/ hierarchy for those "logical" or "virtual"
> devices that back-up those block devices?
> You could even say that RAID and ramdisks -as used in the example
> above- would belong to /sys/devices/"virtual"/raid/ and
> ...../ramdisks/; after all, you have to create those devices before
> being able to attach them (last time I checked):

> In the tree structure it makes sense, because each block
> device, at the end is or a partition (and thus is embedded
> in a "true" block device) or a true block device on a 1:1
> relationship with a physical device.

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.
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