On Tuesday 20 June 2006 11:43, Steven Whitehouse wrote:
> As a further suggestion, I wonder do we really need i_private at all?
> Since we have sb->s_op->alloc_inode and inode->i_sb->s_op->destroy_inode
> if all filesystems did something along the following lines:
>
> struct myfs_inode {
> struct inode i_inode;
> ...
> };
>
> #define MYFS_I(inode) container_of((inode), struct myfs_inode, i_inode)
>
> then it would seem that i_private is redundant. If there is a file
> system which does genuinely need a pointer here (if indeed such a
> filesystem does exist, I haven't actually checked that) then a pointer
> can just be added as the one single other member of (in my example)
> struct myfs_inode.
>
That would mean that all file systems need to implement ->alloc_inode,
which in turn need slab caches that eat consume memory even when
the file system is not mounted.
Something as simple as nfsctl or devpts should not need that.
Arnd <><
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
