From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Andrew Morton <akpm@osdl.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [patch 1/2] own header file for struct page.
Date: Sun, 10 Sep 2006 09:51:54 +0200 [thread overview]
Message-ID: <20060910075154.GA8354@osiris.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0609092248400.6762@scrub.home>
> > In order to get of all these problems caused by macros it seems to
> > be a good idea to get rid of them and convert them to static inline
> > functions. Because of header file include order it's necessary to have a
> > seperate header file for the struct page definition.
> >
> > Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> > Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
> > ---
> >
> > Patches are against git tree as of today. Better ideas welcome of course.
> >
> > include/linux/mm.h | 64 --------------------------------------------
> > include/linux/page.h | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 75 insertions(+), 63 deletions(-)
>
> To avoid the explosion in number of small header files each containing a
> single definition, it would be better to generally split between the
> definitions and implementations, so IMO mm_types.h with all the structures
> and defines from mm.h would be better.
That could be done, but I wouldn't know where to start and where to end.
Moving simply all definitions to mm_types.h doesn't seem to be a good
solution. E.g. having something like "struct shrinker" in mm_types.h
seems to be rather pointless IMHO.
Maybe we can simply leave it by just taking the struct page definition
out for now?
WARNING: multiple messages have this Message-ID (diff)
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Andrew Morton <akpm@osdl.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [patch 1/2] own header file for struct page.
Date: Sun, 10 Sep 2006 09:51:54 +0200 [thread overview]
Message-ID: <20060910075154.GA8354@osiris.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0609092248400.6762@scrub.home>
> > In order to get of all these problems caused by macros it seems to
> > be a good idea to get rid of them and convert them to static inline
> > functions. Because of header file include order it's necessary to have a
> > seperate header file for the struct page definition.
> >
> > Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> > Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
> > ---
> >
> > Patches are against git tree as of today. Better ideas welcome of course.
> >
> > include/linux/mm.h | 64 --------------------------------------------
> > include/linux/page.h | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 75 insertions(+), 63 deletions(-)
>
> To avoid the explosion in number of small header files each containing a
> single definition, it would be better to generally split between the
> definitions and implementations, so IMO mm_types.h with all the structures
> and defines from mm.h would be better.
That could be done, but I wouldn't know where to start and where to end.
Moving simply all definitions to mm_types.h doesn't seem to be a good
solution. E.g. having something like "struct shrinker" in mm_types.h
seems to be rather pointless IMHO.
Maybe we can simply leave it by just taking the struct page definition
out for now?
--
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:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-09-10 7:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-08 11:17 [patch 1/2] own header file for struct page Heiko Carstens
2006-09-08 11:17 ` Heiko Carstens, Heiko Carstens
2006-09-08 16:46 ` Andrew Morton
2006-09-08 16:46 ` Andrew Morton
2006-09-08 18:33 ` Heiko Carstens
2006-09-08 18:33 ` Heiko Carstens
2006-09-08 19:06 ` Andrew Morton
2006-09-08 19:06 ` Andrew Morton
2006-09-08 19:47 ` [patch 1/2] own header file for struct page v2 Heiko Carstens
2006-09-08 19:47 ` Heiko Carstens, Heiko Carstens
2006-09-08 19:48 ` [patch 2/2] convert s390 page handling macros to functions v2 Heiko Carstens
2006-09-08 19:48 ` Heiko Carstens, Heiko Carstens
2006-09-09 21:05 ` [patch 1/2] own header file for struct page Roman Zippel
2006-09-09 21:05 ` Roman Zippel
2006-09-10 7:51 ` Heiko Carstens [this message]
2006-09-10 7:51 ` Heiko Carstens
2006-09-10 13:07 ` [patch 1/2] own header file for struct page v3 Heiko Carstens
2006-09-10 13:07 ` Heiko Carstens, Heiko Carstens
2006-09-10 13:08 ` [patch 2/2] convert s390 page handling macros to functions v3 Heiko Carstens
2006-09-10 13:08 ` Heiko Carstens, Heiko Carstens
2006-09-10 16:25 ` Dave Hansen
2006-09-10 16:25 ` Dave Hansen
2006-09-11 4:22 ` Heiko Carstens
2006-09-11 4:22 ` Heiko Carstens
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=20060910075154.GA8354@osiris.ibm.com \
--to=heiko.carstens@de.ibm.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=schwidefsky@de.ibm.com \
--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.