Alexander Viro wrote:
>
> On Tue, 14 Nov 2000, Daniel Phillips wrote:
>
> > After quite a lot of grepping in 2.4.0-test10 I was unable to find any
> > places where address_mapping->host is not (struct inode *) - are there
> > any?
>
> Currently - none. As soon as block devices go to pagecache we'll have such
> beasts (you need one address_space for all inodes with given major:minor,
> so ->host can't point to any of them). Possibly earlier, if somebody will
> need address_space in some other situation where we need some private
> data, but can't use inode * for them. Block devices were the original
> reason...
>
> IOW, ->host may be anything. For address_space containing inode's data
> having ->host point to inode itself is usually convenient and so far
> all uses of ->host were of that kind. It will change, though - at least
> one application when we need something else is scheduled for 2.5.early.
OK, now I'm confused.
Will there be a sure way of knowing what kind of object ->host points
to? An efficient way would be even nicer. Why would it wrong for
*every* address_space to have an inode and a superblock? Or at least,
if it can't have such a thing, then it should have a null inode instead
of pointing at some other unknown thing. If somebody really needs
->host to be (void *) (meaning they couldn't come up with a way of
making their object look like a file) then maybe they need a private
field in the mapping.
The problem I'm facing right now is: given a random struct page, how do
you find the filesystem/inode it belongs to so you can tell the
filesystem to do something about it?
Even if I can find the filesystem that belongs to a given page, how does
the filesystem find a (struct file *) for the page so it can do
address_space->writepage?
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
