Messages in this thread | | | Date | Mon, 07 Jan 2002 16:27:01 -0500 | From | Jeff Garzik <> | Subject | Re: PATCH 2.5.2.9: ext2 unbork fs.h (part 1/7) |
| |
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.
I am not a fan of anon unions/structs, so I must disagree with Anton here...
> > 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.
agreed, from my side
Jeff
-- Jeff Garzik | Alternate titles for LOTR: Building 1024 | Fast Times at Uruk-Hai MandrakeSoft | The Took, the Elf, His Daughter and Her Lover | Samwise Gamgee: International Hobbit of Mystery - 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/
| |