From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Simple header cleanups
Date: Tue, 2 May 2006 19:53:35 -0700 (PDT) [thread overview]
Message-ID: <e395vf$dcj$1@terminus.zytor.com> (raw)
In-Reply-To: Pine.LNX.4.64.0604271656390.3701@g5.osdl.org
Followup to: <Pine.LNX.4.64.0604271656390.3701@g5.osdl.org>
By author: Linus Torvalds <torvalds@osdl.org>
In newsgroup: linux.dev.kernel
> >
> > Normal userspace programs will simply not care about the contents of the
> > kernel ABI headers - the libc will present them pretty headers adhering
> > to all past, current and future standards.
>
> As long as that is clear - that the kernel ABI headers are _never_ seen by
> normal programs, even indirectly #include'd from the standard include
> headers.
>
For some of them, there isn't really any reason not to; in particular
when it comes to things like ioctl constants and structures that
describe what is functionally an RPC interface between the user-space
application and the kernel -- the library couldn't realistically
intervene even if it wanted to.
This is also by orders of magnitude the fastest evolving part of the
kernel ABI.
When it comes to more serious stuff like "struct stat" it should be
pretty obvious any "struct stat" the kernel exports is going to be
wrong. klibc, which cares about size and not ABI stability, could
export it directly, but it still wants to be able to *choose* which
"struct stat" to use -- on most platform, it's what the kernel calls
"struct stat64", except with a 32-bit dev_t instead of a 64-bit
unsigned long long for st_[r]dev, plus of course appropriate padding.
One solution would of course be to have a purely declarative language
for that stuff. A C program won't use it because a C program *can't*
use it without further processing, and the declarative language
processor is the ideal place for such stuff. In that scenario even
the kernel would have to use a processed version of the ABI
declarations.
An intermediate solution might be to take sparse, and something like
it, and use it as the declarative language processor. Then the kernel
could still use them as C, but the library would have an easy way to
process them. The risk is that something might not.
What David has done is yet one step down from this in ambition level,
but at least he's gotten the ball rolling.
-hpa
next prev parent reply other threads:[~2006-05-03 2:54 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-27 2:13 Simple header cleanups 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
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 [this message]
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='e395vf$dcj$1@terminus.zytor.com' \
--to=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.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.