All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Daniel Phillips <phillips@bonn-fries.net>
Cc: Anton Altaparmakov <aia21@cam.ac.uk>,
	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)
Date: Mon, 07 Jan 2002 16:27:01 -0500	[thread overview]
Message-ID: <3C3A12A5.196C81B7@mandrakesoft.com> (raw)
In-Reply-To: <5.1.0.14.2.20020107134718.025e4d90@pop.cus.cam.ac.uk> <E16NbmV-0001R0-00@starship.berlin>

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

  reply	other threads:[~2002-01-07 21:27 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-07 13:21 PATCH 2.5.2.9: ext2 unbork fs.h (part 1/7) Jeff Garzik
2002-01-07 14:13 ` Anton Altaparmakov
2002-01-07 15:33   ` Daniel Phillips
2002-01-07 21:27     ` Jeff Garzik [this message]
2002-01-08  6:32       ` Daniel Phillips
2002-01-08  6:31         ` Jeff Garzik
2002-01-08  6:38           ` Daniel Phillips
2002-01-07 16:01   ` Anton Altaparmakov
2002-01-07 16:23     ` Daniel Phillips
2002-01-07 17:25     ` Mark Zealey
2002-01-07 15:19 ` Daniel Phillips
2002-01-07 20:54   ` Juan Quintela
2002-01-08  4:10     ` Daniel Phillips
2002-01-07 21:25   ` Jeff Garzik
2002-01-08  3:06     ` Daniel Phillips
2002-01-07 23:48   ` Jeff Garzik
2002-01-08  0:15     ` Andreas Dilger
2002-01-08  0:17       ` Jeff Garzik
2002-01-08  3:28     ` Daniel Phillips
2002-01-07 16:10 ` Daniel Phillips
2002-01-07 19:38   ` Alexander Viro
2002-01-07 21:37     ` Jeff Garzik
2002-01-07 23:28     ` [PATCH 7/7 v2] " Jeff Garzik
2002-01-07 23:49       ` [Ext2-devel] " Andreas Dilger
2002-01-07 23:52         ` Jeff Garzik
2002-01-07 21:32   ` Jeff Garzik
2002-01-07 21:49     ` Arnaldo Carvalho de Melo
2002-01-07 21:58       ` Jeff Garzik
2002-01-07 23:46   ` Jeff Garzik
2002-01-08  0:17     ` [Ext2-devel] " Andreas Dilger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C3A12A5.196C81B7@mandrakesoft.com \
    --to=jgarzik@mandrakesoft.com \
    --cc=aia21@cam.ac.uk \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillips@bonn-fries.net \
    --cc=torvalds@transmeta.com \
    --cc=viro@math.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.