All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Adrian Bunk <bunk@kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	"Robert P. J. Day" <rpjday@crashcourse.ca>,
	kbuild devel list <linux-kbuild@vger.kernel.org>
Subject: Re: [2.6 patch] run all userspace headers through unifdef
Date: Thu, 22 May 2008 09:08:17 +0200	[thread overview]
Message-ID: <20080522070817.GA18607@uranus.ravnborg.org> (raw)
In-Reply-To: <20080521232243.bca09103.akpm@linux-foundation.org>

On Wed, May 21, 2008 at 11:22:43PM -0700, Andrew Morton wrote:
> On Wed, 21 May 2008 20:41:43 +0300 Adrian Bunk <bunk@kernel.org> wrote:
> 
> > Facts:
> > - installing userspace headers is nothing that is required as part of a 
> >   normal kernel build
> > - unifdef is relatively fast
> > - there are sometimes patches moving headers from header-y to unifdef-y 
> >   or the other way round
> > 
> > Instead of constantly seeing headers moving between header-y and 
> > unifdef-y this patch removes unifdef-y and runs all userspace headers 
> > through unifdef.
> > 
> > It also contains some unrelated sorting corrections in the Kbuild files 
> > since I used GNU sort for the semi-automatic conversion of the Kbuild 
> > files.
> > 
> > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> > 
> > ---
> > 
> >  include/asm-alpha/Kbuild              |   11 
> >  include/asm-arm/Kbuild                |    2 
> >  include/asm-cris/Kbuild               |    5 
> >  include/asm-frv/Kbuild                |    5 
> >  include/asm-generic/Kbuild            |    9 
> >  include/asm-generic/Kbuild.asm        |   61 +--
> >  include/asm-ia64/Kbuild               |    9 
> >  include/asm-parisc/Kbuild             |    2 
> >  include/asm-powerpc/Kbuild            |   59 +--
> >  include/asm-s390/Kbuild               |    7 
> >  include/asm-sh/Kbuild                 |    9 
> >  include/asm-sparc/Kbuild              |    7 
> >  include/asm-sparc64/Kbuild            |    5 
> >  include/asm-x86/Kbuild                |   27 -
> >  include/linux/Kbuild                  |  399 ++++++++++++--------------
> >  include/linux/byteorder/Kbuild        |    6 
> >  include/linux/dvb/Kbuild              |    7 
> >  include/linux/netfilter/Kbuild        |   17 -
> >  include/linux/netfilter_arp/Kbuild    |    3 
> >  include/linux/netfilter_bridge/Kbuild |    5 
> >  include/linux/netfilter_ipv4/Kbuild   |    5 
> >  include/linux/netfilter_ipv6/Kbuild   |    3 
> >  include/linux/nfsd/Kbuild             |   12 
> >  include/linux/sunrpc/Kbuild           |    2 
> >  include/sound/Kbuild                  |    9 
> >  include/video/Kbuild                  |    4 
> >  scripts/Makefile.headersinst          |   27 -
> >  27 files changed, 343 insertions(+), 374 deletions(-)
> 
> This is going to be a bit of a pain for everyone - people are forever
> patching those Kbuild files.
> 
> Is there a way in which we can do this in stages?  Treat header-y in
> the same manner as unifdef-y, then get all the unifdef-y's switched over
> to header-y and once that is done, remove the "treat header-y in the same
> manner as unifdef-y" support?

I had following untested patch in mind.

diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 53dae3e..4cbf9ea 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -50,11 +50,9 @@ ifeq ($(obj)$(ALTARCH),include/asm-$(ARCH)$(BIASMDIR))
      _dst := include/asm
 endif
 
-header-y	:= $(sort $(header-y))
-unifdef-y	:= $(sort $(unifdef-y))
-subdir-y	:= $(patsubst %/,%,$(filter %/, $(header-y)))
-header-y	:= $(filter-out %/, $(header-y))
-header-y	:= $(filter-out $(unifdef-y),$(header-y))
+unifdef-y	:= $(sort $(unifdef-y) $(header-y))
+subdir-y	:= $(patsubst %/,%,$(filter %/, $(unidef-y)))
+header-y        :=
 
 # stamp files for header checks
 check-y		:= $(patsubst %,.check.%,$(header-y) $(unifdef-y) $(objhdr-y))

And then separate patches for each directory under include/ so
they are easy to drop in case of conflicts.

Then I expect we will have it 90% sorted out in first week of the merge and
the remaining 10% should be easy to sort out.

PS. I need to dig out my old patch optimizing Makefile.headerinst so we
eventually can simplify Makefile.headerinst and speed it up.
But lacking time...

	Sam

      parent reply	other threads:[~2008-05-22  7:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-18  0:18 [PATCH] KBUILD: Move non-__KERNEL__-checking headers to header-y Robert P. J. Day
2008-05-20  7:08 ` Andrew Morton
2008-05-21  8:36   ` Robert P. J. Day
2008-05-21  8:43     ` Andrew Morton
2008-05-21  9:00       ` David Woodhouse
2008-05-21 10:02         ` Adrian Bunk
2008-05-21 10:47           ` David Woodhouse
2008-05-21 17:41             ` [2.6 patch] run all userspace headers through unifdef Adrian Bunk
2008-05-22  6:22               ` Andrew Morton
2008-05-22  7:00                 ` David Woodhouse
2008-05-22  7:08                   ` Andrew Morton
2008-05-22  7:12                     ` David Woodhouse
2008-05-22  7:28                       ` Robert P. J. Day
2008-05-22  7:37                     ` Adrian Bunk
2008-05-22  7:08                 ` Sam Ravnborg [this message]

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=20080522070817.GA18607@uranus.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=akpm@linux-foundation.org \
    --cc=bunk@kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=rpjday@crashcourse.ca \
    /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.