All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Dave Jones <davej@suse.de>
Cc: Christoph Hellwig <hch@infradead.org>,
	kernel-janitor-discuss@lists.sourceforge.net, linux-mm@kvack.org
Subject: Re: page-flags.h
Date: Thu, 02 May 2002 19:52:40 -0700	[thread overview]
Message-ID: <3CD1FB78.B3314F4B@zip.com.au> (raw)
In-Reply-To: 20020501200452.S29327@suse.de

Dave Jones wrote:
> 
> On Wed, May 01, 2002 at 06:34:14PM +0100, Christoph Hellwig wrote:
>  > This step is wasted work - it will NEVER compile.  Rationale:
>  > the page flags operate on page->flags and without having the definition
>  > of struct page from mm.h this won't do.
>  >
>  > The better idea is IMHO to replace page-flags.h by page.h that also
>  > contains the definition of struct page.
> 
> That's a good point, and something I completley overlooked.
> I wonder if Andrew Morton (who I'm guessing wrote that comment
> in mm.h) has some ingenious plan here..

who, me?

I'd envisaged those 119 files doing:

#include <linux/mm.h>
#include <linux/page-flags.h>

so then anything which includes mm.h but doesn't do any PageFoo()
operations doesn't have to process those macros.

I actually did those 119 edits, but dumped it - there are some
awkward forward, backward and sideward refs in pagemap.h and
highmem.h which need to be fixed up first.  umm..  Move
wait_on_page_locked() into page-flags.h and uninline bio_kmap_irq().

Also, moving bh_kmap(), bh_kunmap() and bh_offset() down into 
their only user, raid5.c will help solve a few ordering nasties.

The other low-hanging fruit here is pulling buffer_head.h
out of fs.h.  But as with page-flags.h, the first step
should be to sort out the .h files which refer to buffers,
then to do .c.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

  reply	other threads:[~2002-05-03  2:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20020501192737.R29327@suse.de>
2002-05-01 17:34 ` page-flags.h Christoph Hellwig
2002-05-01 18:04   ` page-flags.h Dave Jones
2002-05-03  2:52     ` Andrew Morton [this message]
2002-05-03  8:24       ` page-flags.h Christoph Hellwig
2002-05-03 22:41       ` page-flags.h Erik van Konijnenburg
2002-05-03 23:06         ` page-flags.h Andrew Morton
2002-05-03 23:39           ` page-flags.h Dave Jones
2002-05-04  6:46             ` page-flags.h Erik van Konijnenburg
2002-05-14 20:25               ` page-flags.h Andrew Morton
2002-05-15 12:38                 ` page-flags.h Christoph Hellwig
2002-08-29 19:04                 ` page-flags.h Daniel Phillips

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=3CD1FB78.B3314F4B@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=davej@suse.de \
    --cc=hch@infradead.org \
    --cc=kernel-janitor-discuss@lists.sourceforge.net \
    --cc=linux-mm@kvack.org \
    /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.