Messages in this thread |  | | From | Andreas Dilger <> | Date | Wed, 19 Sep 2001 14:26:51 -0600 | Subject | Re: Request: removal of fs/fs.h/super_block.u to enable partition locking |
| |
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
- 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/
|  |