Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 7 Jan 2002 16:27:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 7 Jan 2002 16:27:23 -0500 Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:36108 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id ; Mon, 7 Jan 2002 16:27:07 -0500 Message-ID: <3C3A12A5.196C81B7@mandrakesoft.com> Date: Mon, 07 Jan 2002 16:27:01 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18pre1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Phillips CC: Anton Altaparmakov , torvalds@transmeta.com, viro@math.psu.edu, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, ext2-devel@lists.sourceforge.net Subject: Re: PATCH 2.5.2.9: ext2 unbork fs.h (part 1/7) In-Reply-To: <5.1.0.14.2.20020107134718.025e4d90@pop.cus.cam.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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: > > > > >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/