- 论坛徽章:
- 0
|
the link is:http://kerneltrap.org/node/6536
Posted by Jeremy on 星期五, 四月 28, 2006 - 08:58
David Woodhouse offered a collection of patches aimed at cleaning up Linux kernel headers, explaining that he maintains the Fedora glibc-kernheaders package and has found the process of syncing with the latest kernel to be unnecessarily tedious. Linus Torvalds acknowledged the effort, noting that he preferred to wait until early in the 2.6.18 development cycle before merging the patches as things tend to break, "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."
David responded, "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."
Linus was quick to retort, "if this is work to try to make kernel headers generally palatable to user space, I'm not going to apply it at all. Not now, not early in the 2.6.18 sequence, not EVER. Because that's not a goal I believe in for a moment." He then went on to explain, "in contrast, if this is work to make it eventually _easier_ for _library_ people to decide to upgrade their kernel-related information, I'm ok with it. But that 'target audience' part really is very very important. The target audience should NOT be applications including kernel headers. The target audience should be distributions and library maintainers."
--------------------------------------------------------------------------------
From: David Woodhouse [email blocked]
To: torvalds, [email blocked]
Subject: Simple header cleanups
Date: Thu, 27 Apr 2006 03:13:42 +0100
Andrew (or preferably Linus since these are fairly simple and
unintrusive bug fixes), please pull from my tree at
git://git.infradead.org/hdrcleanup-2.6.git
(Gitweb at http://git.infradead.org/?p=hdrcleanup-2.6.git;a=summary)
This tree contains a number of simple fixes for kernel headers which are
currently exposing things to userspace that should not be present
outside #ifdef __KERNEL__.
Since ifdefs are horrid, these patches tend not to add new ones --
mostly it's a case of moving things inside existing ifdefs, rather than
adding new ones.
Most of the patches are small and self-contained, except for the one
which removes #include <linux/config.h> from everything under include/
The individual commits are as follows:
Remove user-visible references to PAGE_SIZE in include/asm-powerpc/elf.h
Include <linux/jiffies.h> from linux/acct.h only in kernel-private part.
Don't include agp_backend.h in user-visible part of agpgart.h
Use __KERNEL__ to hide kernel-private bits of linux/gameport.h
Export only the appropriate GS_xxx flags to userspace from generic_serial.h
Include various private files only from within __KERNEL__ in genhd.h
Sanitise linux/i2c-algo-ite.h for userspace consumption
Sanitise linux/i2c.h for userspace consumption
Don't include <linux/device.h> from user-visible part of linux/ipmi.h
Remove gratuitous inclusion of <linux/pci.h> from linux/isdn/tpam.h
Sanitise linux/mman.h for userspace consumption
Don't include private files from user-visible part of linux/ncp_fs.h
Don't include <linux/list.h> from user-visible part of linux/msg.h
Don't include <linux/stringify> from user-visible part of linux/net.h
Don't include private headers from user-visible parts of include/linux/nfs*.h
Don't include private headers from user-visible parts of linux/quota.h
Don't include <linux/list.h> from user-visible part of reiserfs_xattr.h
Partially sanitise linux/sched.h for userspace consumption
Don't include <asm/atomic.h> from user-visible part of linux/sem.h
Don't include private headers from user-visible part of linux/signal.h
Move comment in mtd-abi.h to stop confusing unifdef
Don't include <linux/spinlock.h> from user-visible part of linux/wanrouter.h
Don't export CONFIG_COMPAT stuff in linux/usbdevice_fs.h to userspace
Sanitise linux/sunrpc/debug.h for userspace consumption
Don't include private headers from user-visible part of linux/smb_fs.h
Don't include private headers from user-visible part of linux/ext2_fs.h
Don't include private headers from user-visible part of linux/ext3_fs.h
Don't include <linux/config.h> and <linux/linkage.h> from linux/socket.h
Don't include linux/config.h from anywhere else in include/
Sanitise linux/audit.h for userspace consumption, split elf-em.h from elf.h
Sanitise linux/sched.h for userspace consumption
Excluding the one-line files which have just <linux/config.h> removed,
the diffstat looks like this:
asm-m32r/mmu_context.h | 2
asm-powerpc/elf.h | 7 --
asm-ppc/page.h | 2
asm-sparc/system.h | 2
linux/acct.h | 3
linux/agpgart.h | 3
linux/audit.h | 4 -
linux/elf-em.h | 44 +++++++++++++
linux/elf.h | 59 -----------------
linux/ext2_fs.h | 2
linux/ext3_fs.h | 7 --
linux/gameport.h | 6 +
linux/generic_serial.h | 6 +
linux/genhd.h | 12 +--
linux/i2c-algo-ite.h | 7 +-
linux/i2c.h | 9 +-
linux/ipmi.h | 2
linux/mman.h | 12 ++-
linux/msg.h | 2
linux/ncp_fs.h | 5 -
linux/net.h | 3
linux/nfs.h | 8 +-
linux/nfs4.h | 6 -
linux/nfs_fs.h | 39 +++++------
linux/quota.h | 4 -
linux/reiserfs_xattr.h | 3
linux/sched.h | 90 +++++++++++++--------------
linux/sem.h | 2
linux/signal.h | 4 -
linux/smb_fs.h | 4 -
linux/socket.h | 2
linux/sunrpc/debug.h | 24 +++----
linux/usbdevice_fs.h | 2
linux/wanrouter.h | 4 -
mtd/mtd-abi.h | 5 -
864 files changed, 191 insertions(+), 1034 deletions(-)
--
dwmw2
From: Linus Torvalds [email blocked]
Subject: Re: Simple header cleanups
Date: Wed, 26 Apr 2006 19:18:52 -0700 (PDT)
On Thu, 27 Apr 2006, David Woodhouse wrote:
>
> Andrew (or preferably Linus since these are fairly simple and
> unintrusive bug fixes), please pull from my tree at
> git://git.infradead.org/hdrcleanup-2.6.git
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.
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.
Linus
From: Gerrit Huizenga [email blocked]
Subject: Re: Simple header cleanups
Date: Wed, 26 Apr 2006 19:27:27 -0700
On Wed, 26 Apr 2006 19:18:52 PDT, Linus Torvalds wrote:
>
>
> On Thu, 27 Apr 2006, David Woodhouse wrote:
> >
> > Andrew (or preferably Linus since these are fairly simple and
> > unintrusive bug fixes), please pull from my tree at
> > git://git.infradead.org/hdrcleanup-2.6.git
>
> 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.
>
> 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.
>
> Linus
Except there are a few things you can't use in user space now, like
connectors, without including a kernel header file. So, should apps
duplicate the structures and definitions in each and every application and
hopefully notice when the kernel API changes? Seems painful.
Plus, do we really want Apache or other licensed software directly
including GPL header files? Oh what a tangled web we weave when we suck
GPL headers into other applications.
Damned if you do, damned if you don't.
gerrit
From: Linus Torvalds [email blocked]
Subject: Re: Simple header cleanups
Date: Wed, 26 Apr 2006 19:46:29 -0700 (PDT)
On Wed, 26 Apr 2006, Gerrit Huizenga wrote:
>
> Damned if you do, damned if you don't.
Right. Which is why I'm ok with the cleanups, I'm just _not_ ok with them
happening this late in the game (ie I'm hoping to get 2.6.17 out in a
couple of weeks..)
Linus
--------------------------------------------------------------------------------
From: David Woodhouse [email blocked]
Subject: Re: Simple header cleanups
Date: Thu, 27 Apr 2006 03:37:37 +0100
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
From: Linus Torvalds [email blocked]
Subject: Re: Simple header cleanups
Date: Wed, 26 Apr 2006 19:59:10 -0700 (PDT)
On Thu, 27 Apr 2006, David Woodhouse wrote:
>
> 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.
.. and that's generally the job of library maintainers.
I disagree violently with the notion that any normal system should _ever_
have the regular headers have anything to do with "what kernel source is
installed right now". It is untenable to expect kernel developers to have
to worry about user-level header problems.
> 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.
AND WE SHOULD NOT HAVE TO!
Linkages are bad. We _will_ break kernel headers for user space, and
that's just a undeniable fact.
If this is work to try to make kernel headers generally palatable to user
space, I'm not going to apply it at all. Not now, not early in the 2.6.18
sequence, not EVER. Because that's not a goal I believe in for a moment.
In contrast, if this is work to make it eventually _easier_ for _library_
people to decide to upgrade their kernel-related information, I'm ok with
it. But that "target audience" part really is very very important. The
target audience should NOT be applications including kernel headers.
The target audience should be distributions and library maintainers.
Linus
From: David Woodhouse [email blocked]
Subject: Re: Simple header cleanups
Date: Thu, 27 Apr 2006 04:17:51 +0100
On Wed, 2006-04-26 at 19:59 -0700, Linus Torvalds wrote:
> Linkages are bad. We _will_ break kernel headers for user space, and
> that's just a undeniable fact.
Agreed. And distributions and library maintainers _will_ fix them. Are
we to deny those people the tools which will help them to keep track of
our breakage and submit patches to fix it?
The current situation is that they all go off and do their own thing to
work around it, instead of submitting those fixes. We need to do better
than that.
> If this is work to try to make kernel headers generally palatable to user
> space, I'm not going to apply it at all. Not now, not early in the 2.6.18
> sequence, not EVER. Because that's not a goal I believe in for a moment.
Kernel headers are never going to be generally palatable to user space.
That's always been clear, and it's a large part of the reason why we
wanted the 'export' step -- so that a _subset_ of headers could be
copied out for use by userspace, rather than a complete tarball as has
been used in the past.
> In contrast, if this is work to make it eventually _easier_ for _library_
> people to decide to upgrade their kernel-related information, I'm ok with
> it. But that "target audience" part really is very very important. The
> target audience should NOT be applications including kernel headers.
>
> The target audience should be distributions and library maintainers.
And those are the people I've been talking to over the last week or so.
All the distributions have their own hacks and patches and scripts which
mangle the kernel headers. Some from a vaguely current copy, some from a
copy which was forked years ago and kept vaguely up to date with
syscalls and new ioctls by hand. The results differ wildly from
distribution to distribution, and the end result for the _user_ is a
steaming inconsistent pile of crap.
What I'm trying to do here is centralise that process and let people
work on it together -- and yes, it still needs to go through
distributions and library maintainers. The point is not to go back to
making symlinks from /usr/include/{linux,asm} to the kernel directories
again -- that would be a retrograde step. The point is that distro and
library maintainers can work from what is provided by the kernel to
achieve a consistent and useful result.
That _is_ needed. It's a quality of implementation issue.
--
dwmw2
From: Linus Torvalds [email blocked]
Subject: Re: Simple header cleanups
Date: Wed, 26 Apr 2006 20:31:00 -0700 (PDT)
On Thu, 27 Apr 2006, David Woodhouse wrote:
>
> Agreed. And distributions and library maintainers _will_ fix them. Are
> we to deny those people the tools which will help them to keep track of
> our breakage and submit patches to fix it?
No. As mentioned, as long as the target audience is distributions and
library maintainers, I definitely think we should do help them as much as
possible. Our problems have historically been "random people" who have
/usr/include/linux being the symlink to "kernel source of the day", which
is an unsupportable situation.
(And yes, for a short while back in the early nineties, that symlink was
even the proper thing to do. But exactly because it's unsupportable, it
pretty quickly got to be a "don't do that then", but I still occasionally
hear from people who use bad distributions).
Linus |
|
免费注册
发表于 2006-05-18 22:19