mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: Simple header cleanups
Date: Thu, 27 Apr 2006 03:37:37 +0100	[thread overview]
Message-ID: <1146105458.2885.37.camel@hades.cambridge.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0604261917270.3701@g5.osdl.org>

On Wed, 2006-04-26 at 19:18 -0700, Linus Torvalds wrote:
> Hmm. Every time we've done this in the past, something has broken, so I'd 
> actually _much_ rather wait until early in the 2.6.18 cycle than do it 
> now.

OK. I've tried to be _very_ conservative with this set -- it mostly is
just a case of moving #includes from one part of a header file to
another so they aren't exposed to userspace. I figured the more
interesting stuff could come later.

But if you'd rather have it only in -mm only for now, that's fine.

> Yeah, people shouldn't include kernel headers, but if they didn't, this 
> patch wouldn't matter. And when they do, patches like this tends to show 
> some strange app that depends on the current header layout.. Gaah.

Well, yes, but we all know that people _have_ to include kernel headers.
We can't just bury our head in the sand and say "they mustn't do that".
The kernel headers contain all the juicy stuff like structure
definitions and ioctls which you _need_ in order to communicate with the
kernel.

The problem is that we don't actually have any _discipline_ about how we
throw our kernel headers over the wall. We never even _think_ about how
usable they are in userspace, or how what we're doing will affect
userspace.

That's why there are so many silly little cleanups which I had to make
just to be able to use some recent kernel headers sanely again in
userspace, instead of the ancient fork we'd taken in Fedora from a 2.4
kernel.

The answer to this lies in my other git tree, at
git://git.infradead.org/hdrinstall-2.6.git -- again in gitweb, at
http://git.infradead.org/?p=hdrinstall-2.6.git;a=summary

Based on an original implementation by Arnd Bergmann, this implements
new 'make headers_install' target for the kernel Makefiles, which
exports a selection of the contents of our include/ directories to
userspace, having run them through unifdef where appropriate.

This gives us a pristine set of headers which _are_ suitable for
userspace inclusion. I've been talking to maintainers of the
'kernel-headers' or similar packages in other distributions, and we seem
to have a consensus that this is going to be useful. All the
distributions can ship basically the _same_ set of headers, instead of
all doing their own thing to clean them up, and getting it inconsistent
across distros.

As well as achieving that laudable goal, the export step also allows us
(and in particular our janitor-types) to _read_ through the headers
which userspace gets, and start to clean them up a bit more, cleaning up
namespace pollution and removing things which are still visible but
which shouldn't be. It allows us to take a diff of the _exported_
headers between one release and the next, and see the user-visible
changes in isolation.

-- 
dwmw2


  parent reply	other threads:[~2006-04-27  2:37 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-27  2:13 David Woodhouse
2006-04-27  2:18 ` Linus Torvalds
2006-04-27  2:27   ` Gerrit Huizenga
2006-04-27  2:46     ` Linus Torvalds
2006-04-27  3:00     ` David Woodhouse
2006-04-27  4:32       ` Gerrit Huizenga
2006-04-27  2:37   ` David Woodhouse [this message]
2006-04-27  2:59     ` Linus Torvalds
2006-04-27  3:17       ` David Woodhouse
2006-04-27  3:31         ` Linus Torvalds
2006-04-27  3:41           ` David Woodhouse
2006-04-27  7:10           ` Denis Vlasenko
2006-04-27  7:23             ` Arjan van de Ven
2006-04-27  8:49             ` Krzysztof Halasa
2006-04-27 11:03               ` Arnd Bergmann
2006-04-27 21:37           ` Adrian Bunk
2006-04-27 22:00             ` Linus Torvalds
2006-04-27 23:11               ` David Woodhouse
2006-04-27 23:12               ` Adrian Bunk
2006-04-28  0:01                 ` Linus Torvalds
2006-04-28  0:55                   ` David Woodhouse
2006-04-28 15:32                   ` Jan Engelhardt
2006-04-28 15:37                     ` David Woodhouse
2006-04-28 15:59                       ` Arjan van de Ven
2006-04-28 16:01                       ` Kyle Moffett
2006-04-29 10:33                         ` Krzysztof Halasa
2006-05-03  2:53                   ` H. Peter Anvin
2006-04-30  9:38               ` Peter Chubb
2006-04-30  9:59                 ` David Woodhouse
2006-04-30 21:48                   ` Peter Chubb
2006-04-27 15:05   ` 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=1146105458.2885.37.camel@hades.cambridge.redhat.com \
    --to=dwmw2@infradead.org \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.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®