All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Christoph Hellwig <hch@lst.de>
Cc: marcelo@conectiva.com.br, linux-kernel@vger.kernel.org,
	"Stephen C. Tweedie" <sct@redhat.com>,
	Joe Thornber <joe@fib011235813.fsnet.co.uk>
Subject: Re: [PATCH] simplify b_inode usage
Date: Tue, 13 Aug 2002 14:10:10 -0700	[thread overview]
Message-ID: <3D5975B2.66B4B215@zip.com.au> (raw)
In-Reply-To: 20020813171024.A4365@lst.de

Christoph Hellwig wrote:
> 
> Current the b_inode of struct buffer_head is a pointer to an inode, but
> it only always used as bool value.  This patch changes it to an simple
> int (yes, I know some people have ideas for a flag that uses less space,
> but that can be easily done ontop of this cleanup).  The advantage is
> that we don't have to pass in the inode into buffer_insert_inode_queue/
> buffer_insert_inode_data_queue and can merge them into a more general
> buffer_insert_list, with inline wrappers around it.  reiserfs can now
> use buffer_insert_list directly and embedd a simple list_head instead
> of a full static inode into it's journal.
> 
> A similar cleanup has already been done in early 2.5, but the b_inode
> flag is completly gone there now.
> 

Current ext3 CVS (ie: 2.4.20 candidate code) is using b_inode
as an inode *.   Stephen has acked a proposal to stop doing that,
but let's double check with him first.

Also, Joe Thornber needs to add another pointer to struct buffer_head
for LVM2 reasons.  If we collapse b_inode into a b_flags bit then
Joe gets his pointer for free (bh stays at 48 bytes on ia32).

So I'd suggest you just go ahead and do it that way.  (I had a patch
for that but seem to have misplaced it).

  reply	other threads:[~2002-08-13 21:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-13 15:10 [PATCH] simplify b_inode usage Christoph Hellwig
2002-08-13 21:10 ` Andrew Morton [this message]
2002-08-14  7:43   ` Joe Thornber
2002-08-16 12:36   ` Christoph Hellwig
2002-08-16 14:22     ` Andrew Morton

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=3D5975B2.66B4B215@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=hch@lst.de \
    --cc=joe@fib011235813.fsnet.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=sct@redhat.com \
    /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.