Messages in this thread | | | From | "Perez-Gonzalez, Inaky" <> | Subject | RE: Flaw in the driver-model implementation of attributes | Date | 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/
| |