Re: Request: removal of fs/fs.h/super_block.u to enable partition locking

[Andreas Dilger]

On Sep 19, 2001  20:28 +0100, Alan Cox wrote:
> > [Re: removing the fs union from struct inode]
> 
> However you don't need to remove anything for that

No, but there are other things which will probably remove the union from
struct inode in 2.5.  Since it is starting to get so huge, it is a penalty
for filesystems that don't need all of this space in each inode.  Al Viro
has patches already to move some of the fs types into their own slab cache.

It may make sense to leave a small number of bytes inside the inode struct
(they would be used anyways for alignment/padding in the inode slab) for
filesystems that only have very small space requirements.

If you move the union to an external declaration, you can do things like:

static inline struct fs_inode_info *FSI(inode)
{
	if (sizeof(union inode_fs_data) >= sizeof(struct fs_inode_info))
		return (struct fs_inode_info *)&inode->u.generic_ip;
	else
		return (struct fs_inode_info *)inode->u.generic_ip;
}

and the compiler should pick one or the other by virtue of the fact that
it is comparing constants which can be resolved at compile time.  Sadly
sizeof cannot be handled by the preprocessor so the following does not work:

#if sizeof(union inode_fs_data) >= sizeof(struct fs_inode_info)
#define FSI(inode) ((struct fs_inode_info *)&(inode)->u.generic_ip);
#else
#define FSI(inode) ((struct fs_inode_info *)(inode)->u.generic_ip);
#endif

which would guarantee that we do not bloat the code or impose run-time
overhead.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert