In article <[EMAIL PROTECTED]>,
Alexander Viro <[EMAIL PROTECTED]> wrote:
>On Tue, 15 May 2001, H. Peter Anvin wrote:
>
>> Alexander Viro wrote:
>> > >
>> > > None whatsoever. The one thing that matters is that noone starts making
>> > > the assumption that mapping->host->i_mapping == mapping.
>> >
>> > One actually shouldn't assume that mapping->host is an inode.
>> >
>>
>> What else could it be, since it's a "struct inode *"? NULL?
>
>struct block_device *, for one thing. We'll have to do that as soon
>as we do block devices in pagecache.
No, Al. It's an inode. It was a major mistake to ever think anything
else.
I see your problem, but it's not a real problem. What you do for block
devices (or anything like that where you might have _multiple_ inodes
pointing to the same thing, is to just create a "virtual inode", and
have THAT be the one that the mapping is associated with. Basically
each "struct block_device *" would have an inode associated with it, to
act as a anchor for things like this.
What is "struct inode", after all? It's just the virtual representation
of a "entity". The inodes associated with /dev/hda are not the inodes
associated with the actual _device_ - they are just on-disk "links" to
the physical device.
[ Aside: there are good arguments to _not_ embed "struct inode" into
"struct block_device", but instead do it the other way around - the
same way we have filesystem-specific inode data inside "struct inode"
we can easily have device-type specific data there. And it makes a
whole lot more sense to attach a mount to an inode than it makes to
attach a mount to a "struct block_device".
Done right, we could eventually get rid of "loopback block devices".
They'd just be inodes that aren't of type "struct block_device", and
the index to "struct buffer_head" would not be <block_deve *, blknr,
size>, but <inode *, blknr, size>. See? The added level of indirection
is one that we actually already _use_, it's just that we have this
loopback device special case for it..
In a "perfect" setup you could actually do "mount -t ext2 file /mnt/x"
without having _any_ loopback setup or anything like that, simply
because you don't _need_ it. It would be automatic. ]
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
