Re: Flaw in the driver-model implementation of attributes

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.