lkml.org 
[lkml]   [2001]   [Dec]   [26]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 27 Dec 2001 01:35:52 -0200
FromArnaldo Carvalho de Melo <>
SubjectRe: [RFC] [PATCH] Clean up fs.h union for ext2
Em Wed, Dec 26, 2001 at 10:28:09PM -0500, Legacy Fishtank escreveu:
> On Thu, Dec 27, 2001 at 04:21:42AM +0100, Daniel Phillips wrote:
> > --- ../2.4.17.clean/include/linux/fs.h	Fri Dec 21 12:42:03 2001
> > +++ ./include/linux/fs.h	Wed Dec 26 23:30:55 2001
> > @@ -478,7 +478,7 @@
> >  	__u32			i_generation;
> >  	union {
> >  		struct minix_inode_info		minix_i;
> > -		struct ext2_inode_info		ext2_i;
> > +		struct ext2_inode_info		ext2_inode_info;
> >  		struct ext3_inode_info		ext3_i;
> >  		struct hpfs_inode_info		hpfs_i;
> >  		struct ntfs_inode_info		ntfs_i;
> 
> Change in principle looks good except IMHO you should go ahead and
> remove the ext2 stuff from the union...  (with the additional changes
> that implies)

Jeff, he's trying to go incremental, the idea is to make the union
something like ->i_fs_private (void pointer) or something like that, or do
like I did for the struct sock case, using a per fs slabcache, to avoid the
extra allocation for the private area, Al thinks that this is not needed,
but Daniel thinks it can be worth it, doing it incrementally we can test
both approaches and avoid getting to big a patch. But yes, the idea is to
kill the union completely and remove all the fs specific includes in fs.h.

After the access to the union is abstracted, we can do the next step, which
is to remove the union, touching then only the function/macro that
abstracts the access to the fs specific data.

So, yes, the ext2 stuff will be removed, as all the other fs specific stuff
8)

- Arnaldo
-
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/

\
 
 \ /
  Last update: 2005-03-22 12:14    [from the cache]
©2003-2008