very clear now, thanks. I though the fs you were talking about was
mounted on the blkdev, while it is instead the one where the blkdev
inode cames from. Usually people keeps bldkev in /dev and nobody
unmounts /dev that's why I didn't noticed and thought about it, sorry.
> > If we need to avoid the bumping of i_count and to allocate something
> > dynamically that will be the bd_mapping address space, we don't need a
> > new fake_inode there too, we just need to share the new physical
> > pagecahce address space. Such physical i_mapping address space is the
>
> What are you going to use as mapping->host for it?
the only info we'd need from the host is the host->i_rdev, so why can't
we get it from the file->f_dentry->d_inode->i_rdev? In general I don't
like very much the fake inodes with the zillon of unused fields (they
just looks confusing due their unused fields), but well if you for
whatever reason prefer to keep doing page->mapping->host->i_rdev or if
file->f_dentry->d_inode->i_rdev has a problem I'm pretty much ok with
the fake_inode there too.
Andrea
-
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/