Messages in this thread |  | | Date | Tue, 17 Sep 2002 09:11:26 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: route inode->block_device in 2.5? |
| |
On Tue, 17 Sep 2002, Anton Altaparmakov wrote:
> At 17:22 12/09/02, Peter T. Breuer wrote: > >Is there a pointer chain by which one can get to the struct > >block_device of the underlying block device from an inode? > > struct inode->i_sb (== struct super_block)->s_bdev (== struct block_device).
... is meaningful only for local filesystems that happen to live on a single block device and even that only if said local filesystems want to use the helper functions that expect ->s_bdev to be there.
IOW, upper layers have no business using that field - it's for the filesystem-specific code and helper functions such code decides to call.
There might be such thing as underlying block device of a <foofs> inode. There is no such thing as underlying block device of an inode. For quite a few filesystems it simply makes no sense. For some it does and for many of them ->i_sb->s_bdev indeed would give you that, but that's it - it _is_ fs-dependent and there is no guarantee that e.g. minixfs in 2.6.4-pre2 won't change leaving ->s_bdev NULL and storing pointer to block device elsewhere (at which point it will have to switch from sb_bread() and friends to something else).
The point being, VFS doesn't know, doesn't care and shouldn't presume anything about private details of fs implementation. Notice that VFS != "all stuff in fs/*.c" - the latter includes a pile of library functions intended for use by filesystem code. That stuff obviously can make whatever assumptions about fs internals it wants - the callers know what data structures they have and can decide what can be called.
- 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/
|  |