All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andreas Dilger <adilger@clusterfs.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Header files and the kernel ABI
Date: Thu, 25 Jul 2002 00:07:30 -0700	[thread overview]
Message-ID: <3D3FA3B2.9090200@zytor.com> (raw)
In-Reply-To: 20020725065109.GO574@clusterfs.com

Andreas Dilger wrote:
> 
> I had thought on this briefly in the past, and my take would be for these
> ABI definition files to live directly in /usr/include/linux for user space
> (just as glibc puts its own sanitized copy of the kernel headers there)
> and the appropriate ABI headers are included as needed from the kernel.
> 

Given no legacy, I would agree with this, but I think it would imply bad 
legacy both on the kernel and the libc (it's not just glibc, either) side.

> The kernel side would be something like <linux/scsi.h> includes
> <linux/abi/scsi.h> or whatever, but in the future this can be included
> directly as needed throughout the kernel.  The existing kernel
> <linux/*.h> headers would also have extra kernel-specific data in them.
> 
> The same could be done with the user-space headers, but I think that
> is missing the point that the linux/abi/*.h headers should define _all_
> of the abi, so we may as well just use that directly.

Except now the paths are gratuitously different between kernel 
programming and non-kernel programming, and we create a much harder 
migration problem.  I'd rather leave the linux/* namespace to the 
user-space libc to do whatever backwards compatibility cruft they may 
consider necessary, for example, <linux/io.h> might #include <sys/io.h> 
since some user space apps bogusly included the former name.  Leaving 
that namespace available for backwards compatibility hacks avoids those 
kinds of problems.

> Essentially "all" this would mean is that we take the existing headers,
> remove everything which is inside #ifdef __KERNEL__ (and all of the
> other kernel-specific non-abi headers that are included) and we are
> done.  The kernel header now holds only things that were inside the
> #ifdef __KERNEL__ (or should have been), and #include <linux/abi/foo.h>.

Exactly.

	-hpa



  reply	other threads:[~2002-07-25  7:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-25  6:28 Header files and the kernel ABI H. Peter Anvin
2002-07-25  6:51 ` Andreas Dilger
2002-07-25  7:07   ` H. Peter Anvin [this message]
2002-07-25  7:32     ` Andreas Dilger
2002-07-25 16:29       ` Oliver Xymoron
2002-07-25 16:31         ` H. Peter Anvin
2002-07-25 18:19           ` Erik Andersen
2002-07-25 20:03             ` Oliver Xymoron
2002-07-27 11:29               ` Eric W. Biederman
2002-07-25 16:30       ` H. Peter Anvin
2002-07-25  8:00 ` DervishD
2002-07-25 13:08 ` Brad Hards
2002-07-25 16:09   ` DervishD
2002-07-25 16:17   ` H. Peter Anvin
2002-07-25 18:22     ` Erik Andersen
2002-07-31 21:37 ` Kernel ABI BoF at Linux-Kongress? [was: Header files and the kernel ABI] Brad Hards
  -- strict thread matches above, loose matches on Subject: below --
2002-07-25 21:13 Header files and the kernel ABI dank
2002-07-26  2:37 ` jw schultz

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=3D3FA3B2.9090200@zytor.com \
    --to=hpa@zytor.com \
    --cc=adilger@clusterfs.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.