All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	geert@linux-m68k.org, ralf@linux-mips.org,
	linux-mm <linux-mm@kvack.org>
Subject: Re: [patch] [RFC] make WANT_PAGE_VIRTUAL a config option
Date: Thu, 16 Dec 2004 17:14:10 -0800	[thread overview]
Message-ID: <1103246050.13614.2571.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.61.0412170150080.793@scrub.home>

On Thu, 2004-12-16 at 16:51, Roman Zippel wrote:
> Could you explain a bit more, what exactly the problem is?

The symptom is that you'll add some new function to a header, say
mmzone.h.  You get some kind of compile error that a structure that you
need is not fully defined (usually because it is predeclared "struct
foo;").  This happens when you do either a structure dereference on a
pointer, or do some other kind of pointer arithmetic on it outside of a
macro.

Your first instinct is usually to go find where that structure is
declared and make sure that the header in which it's declared is
included in the header in which you're working.  Doing this gets rid of
your immediate problem, but usually causes another.  This is because
something in the other header needs something that's defined in the
header that *you're* working on, and needs the reverse order of
includes.

So, what always happens now is that someone just makes a #define.  Since
these aren't evaluated until they're actually used in the code, they get
put after all of the headers naturally and everything compiles.  

Here's a prime example of what you get from include/asm-i386/mmzone.h:

#define pfn_to_page(pfn)                                                \
({                                                                      \
        unsigned long __pfn = pfn;                                      \
        int __node  = pfn_to_nid(__pfn);                                \
        &node_mem_map(__node)[node_localnr(__pfn,__node)];              \
})

Not that this is horrible, but it sure does get annoying, and tends to
be more type-unsafe than your standard static inline.

What I want to do is make sure that, when you include a header, you get
what you need, and only what you need.  Doing this pervasively presents
the possibility of actually understanding the header dependencies, and
being able to avoid almost all of the hackery that goes along with
avoiding them when you *don't* fully understand.

Remember, *structures* can never have truly circular dependencies. I'm
just trying to start expressing that in the header layout.  

-- Dave


WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <haveblue@us.ibm.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	geert@linux-m68k.org, ralf@linux-mips.org,
	linux-mm <linux-mm@kvack.org>
Subject: Re: [patch] [RFC] make WANT_PAGE_VIRTUAL a config option
Date: Thu, 16 Dec 2004 17:14:10 -0800	[thread overview]
Message-ID: <1103246050.13614.2571.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.61.0412170150080.793@scrub.home>

On Thu, 2004-12-16 at 16:51, Roman Zippel wrote:
> Could you explain a bit more, what exactly the problem is?

The symptom is that you'll add some new function to a header, say
mmzone.h.  You get some kind of compile error that a structure that you
need is not fully defined (usually because it is predeclared "struct
foo;").  This happens when you do either a structure dereference on a
pointer, or do some other kind of pointer arithmetic on it outside of a
macro.

Your first instinct is usually to go find where that structure is
declared and make sure that the header in which it's declared is
included in the header in which you're working.  Doing this gets rid of
your immediate problem, but usually causes another.  This is because
something in the other header needs something that's defined in the
header that *you're* working on, and needs the reverse order of
includes.

So, what always happens now is that someone just makes a #define.  Since
these aren't evaluated until they're actually used in the code, they get
put after all of the headers naturally and everything compiles.  

Here's a prime example of what you get from include/asm-i386/mmzone.h:

#define pfn_to_page(pfn)                                                \
({                                                                      \
        unsigned long __pfn = pfn;                                      \
        int __node  = pfn_to_nid(__pfn);                                \
        &node_mem_map(__node)[node_localnr(__pfn,__node)];              \
})

Not that this is horrible, but it sure does get annoying, and tends to
be more type-unsafe than your standard static inline.

What I want to do is make sure that, when you include a header, you get
what you need, and only what you need.  Doing this pervasively presents
the possibility of actually understanding the header dependencies, and
being able to avoid almost all of the hackery that goes along with
avoiding them when you *don't* fully understand.

Remember, *structures* can never have truly circular dependencies. I'm
just trying to start expressing that in the header layout.  

-- Dave

--
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/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2004-12-17  1:14 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-16 21:56 [patch] [RFC] make WANT_PAGE_VIRTUAL a config option Dave Hansen
2004-12-16 21:56 ` Dave Hansen
2004-12-17  0:36 ` Roman Zippel
2004-12-17  0:36   ` Roman Zippel
2004-12-17  0:42   ` Dave Hansen
2004-12-17  0:42     ` Dave Hansen
2004-12-17  0:51     ` Roman Zippel
2004-12-17  0:51       ` Roman Zippel
2004-12-17  1:14       ` Dave Hansen [this message]
2004-12-17  1:14         ` Dave Hansen
2004-12-17  2:50         ` Roman Zippel
2004-12-17  2:50           ` Roman Zippel
2004-12-17  4:24           ` Dave Hansen
2004-12-17  4:24             ` Dave Hansen
2004-12-17 13:26             ` Roman Zippel
2004-12-17 13:26               ` Roman Zippel
2004-12-17 15:59               ` Dave Hansen
2004-12-17 15:59                 ` Dave Hansen
2004-12-17 20:27                 ` Roman Zippel
2004-12-17 20:27                   ` Roman Zippel
2004-12-17 21:48                   ` Dave Hansen
2004-12-17 21:48                     ` Dave Hansen
2004-12-18  0:52                     ` Roman Zippel
2004-12-18  0:52                       ` Roman Zippel
2004-12-20 14:49                       ` Dave Hansen
2004-12-20 14:49                         ` Dave Hansen
2004-12-20 20:45                         ` Roman Zippel
2004-12-20 20:45                           ` Roman Zippel
2004-12-17  2:01       ` Dave Hansen
2004-12-17  2:01         ` Dave Hansen

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=1103246050.13614.2571.camel@localhost \
    --to=haveblue@us.ibm.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ralf@linux-mips.org \
    --cc=zippel@linux-m68k.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.