Re: Flaw in the driver-model implementation of attributes

viro@parcelfarce.linux.theplanet.co.uk
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 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/