RE: Flaw in the driver-model implementation of attributes

Perez-Gonzalez, Inaky (inaky.perez-gonzalez@intel.com)
Wed, 18 Jun 2003 12:52:57 -0700


> From: viro@parcelfarce.linux.theplanet.co.uk
[mailto:viro@parcelfarce.linux.theplanet.co.uk]
>
> > 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.

Thank you }:) - we like it or not, data goes somewhere.

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

Sure, there: /sys/devices/"virtual"/nbd/0

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

/sys/devices/"virtual"/raid/0

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

/sys/devices/"virtual"/loopback/0

Don't you have to do "-o loop" when you mount a loopback?
... same thing happens with nbd and RAID, you have to
tell the kernel to create the actual devices (or it
does); that they show up nowhere in sysfs (yet) is different.

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)
-
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/