mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: torvalds@osdl.org, akpm@osdl.org
Cc: sam@savnborg.org, arnd@arndb.de, jbailey@ubuntu.com,
	Tim Yamin <plasmaroo@gentoo.org>,
	Bernhard Rosenkraenzer <bero@arklinux.org>,
	alan@lxorguk.ukuu.org.uk, Thorsten Kukuk <kukuk@suse.de>,
	Clint Adams <schizo@debian.org>,
	linux-kernel@vger.kernel.org
Subject: [GIT *] make headers_install
Date: Tue, 27 Jun 2006 23:12:52 +0100	[thread overview]
Message-ID: <1151446372.6394.295.camel@pmac.infradead.org> (raw)

Linus, please pull from git://git.infradead.org/hdrinstall-2.6.git

This contains an implementation of a 'make headers_install' target for
the kernel -- based on original work by Arnd Bergmann, modifed my myself
and then cleaned up by Sam. This copies _selected_ kernel headers out to
a separate directory, passing them through sed and BSD's 'unifdef' tool
to remove parts which userspace should not see.

(The BSD 'unifdef' tool is available at least in Fedora and Debian
through their standard package management tools. I believe that Sam
intends to follow up with a patch to add our own copy of unifdef into
the kernel scripts/ directory, as soon as he's fixed the dependency
issues with that.)

This isn't a departure from our current policy that random userspace
must not poke at kernel private headers. It's just an attempt to impose
some control over those places where we have to accept that people _do_
use the kernel's headers -- when building system libraries and tools,
and when building compilers.

Currently, the compiler-build scripts just use 'cp -a', while the
distributions tend to do their own thing to make it _slightly_ saner
than that, although it's a lot of work to do so. The result is wildly
inconsistent and often exposes things which we really don't want
userspace to have copies of.

By adding a 'make headers_install' target to the kernel, we regulate
those people who really do have to use kernel headers, and we can ensure
that we have a _consistent_ set of headers across all distributions,
which contains only what we _need_ to expose; ioctl definitions, etc.

An additional benefit is that comparing the results of 'make
headers_install' from one kernel release to the next allows us to spot
kernel<->user ABI changes in isolation and give them the extra review
that they deserve. I've already caught and fixed one potential problem
with 32-bit userspace on a 64-bit kernel this way.

The result of this export is already being used in the Fedora Core 6
test releases, and other distributions are either looking at switching
over to it or have done so already.

Ignoring the new Kbuild files which just list the files to be exported
from each directory under include/, the diffstat is as follows:

 Makefile                              |   17 ++++
 scripts/Makefile.headersinst          |  158 +++++++++++++++++++++++++++++++++
 scripts/hdrcheck.sh                   |    8 ++
 49 files changed, 399 insertions(+), 0 deletions(-)

David S. Miller:
      Restrict headers exported to userspace for SPARC and SPARC64

David Woodhouse:
      Basic implementation of 'make headers_install'
      Basic implementation of 'make headers_check'
      Add generic Kbuild files for 'make headers_install'
      Add Kbuild file for PowerPC 'make headers_install'
      Add Kbuild file for x86_64 'make headers_install'
      Add Kbuild file for i386 'make headers_install'
      Add Kbuild file for S390 'make headers_install'
      Add Kbuild file for IA64 'make headers_install'
      Add Kbuild file for SPARC 'make headers_install'
      Add Kbuild file for Alpha 'make headers_install'
      Add empty Kbuild files for 'make headers_install' in remaining arches.

Jean Delvare:
      Remove <linux/i2c-id.h> and <linux/i2c-algo-ite.h> from userspace export

-- 
dwmw2


             reply	other threads:[~2006-06-27 22:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-27 22:12 David Woodhouse [this message]
2006-06-28 23:44 ` Ralf Baechle
2006-06-29  0:22   ` David Woodhouse
2006-07-02  9:57 David Woodhouse

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=1151446372.6394.295.camel@pmac.infradead.org \
    --to=dwmw2@infradead.org \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arnd@arndb.de \
    --cc=bero@arklinux.org \
    --cc=jbailey@ubuntu.com \
    --cc=kukuk@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=plasmaroo@gentoo.org \
    --cc=sam@savnborg.org \
    --cc=schizo@debian.org \
    --cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®