Re: PATCH 2.5.2.9: ext2 unbork fs.h (part 1/7)

[Anton Altaparmakov]

At 15:33 07/01/02, Daniel Phillips wrote:
>On January 7, 2002 03:13 pm, Anton Altaparmakov wrote:
> > Goodie. Now we need benchmarks for all the approaches... (-;
> >
> > At 13:21 07/01/02, Jeff Garzik wrote:
> > <snip>
> > >patch7: implement ext2 use of s_op->{alloc,destroy}
> > >
> > >         at this point we have what Linus described:
> > >
> > >                 struct ext2_inode_info {
> > >                         ...ext2 stuff...
> > >                         struct inode inode;
> > >                 };
> >
> > If we were to raise compiler requirements to gcc-2.96 or later this could
> > be simplified with an annonymous struct (having elements in struct inode
> > with the same name as elements in ...ext2 stuff... should be a shooting
> > offence IMO):
> >
> >          struct ext2_inode_info {
> >                  ...ext2 stuff...
> >                  struct inode;
> >          };
> >
> > Advantage of this would be that as far as the fs is concerned there is 
> only
> > one inode and each element can just be dereferenced straight away without
> > need to think was that the generic inode or the fs inode and without need
> > for keeping two pointers around. This leads to simpler code inside the
> > filesystems once they adapt.
>
>Interesting, it's something I've always wanted to be able to do.  But I
>suppose the compiler requirement is a stupport.

Yes. I wonder if gcc people can be persuaded to backport annonymous 
structures and unions into gcc-2.95...?

> > Of course fs which are not adapted would still just work with the fs_i()
> > and fs_sb() macros and/or using two separate pointers.
>
>Yes, the fs_* macros are the really critical part of all this.  I'd like to
>get them in early, while we hash out the rest of it.  I think Jeff supports
>me in this, possibly Al as well.

Absolutely. The macros (or inline functions) are essential to give us the 
ability to play with the internal implementation at will. The sooner they 
are merged into the kernels (preferably both 2.4 and 2.5 considering they 
don't actually change how things work) the better.

Best regards,

Anton