... 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 firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/