Re: bcc dpmi ver1.2.0

[Ryan Underwood <nemesis-lists@icequake.net>]

[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]


On Mon, Jun 14, 2004 at 01:00:44AM -0500, R.L. Horn wrote:
> On Mon, 14 Jun 2004, Stas Sergeev wrote:
> 
> > Are you sure you are upgrading glibc with patches?
> 
> The kernel.  <linux/*> are kernel headers, not part of glibc, but the
> distributors appear to have muddied the waters considerably.  (So, what
> else is new?)
[..]

> It sounds as though the distributors are maintaining multiple, possibly
> disparate, copies of the kernel headers.

There's a good reason for this.  Building userspace applications against
kernel headers creates the very real possibility that a kernel upgrade
may break binary compatibility, because the interfaces may change from
kernel to kernel.  The purpose of /usr/include/linux is to provide a
stable set of headers for compiling applications that does not include
things that might break as the structure of the kernel changes.  It
also means that the structure of the developer and user's machine with
respect to compiling applications will be the same, which is obviously
a good thing for QA and bug-reports.

The userspace headers are almost always behind the kernel ones in terms
of what interfaces are supported, so if you have something that is
building against the version 234 interface of ioctl xyz, you should
probably add the header to the source of your application.
#including a kernel header directly instead is a hack; not only will
your binary potentially not work on a different kernel version, but that
interface may not be available in that kernel header on the user's
machine (if they even have a kernel source installed).

Think of the stable headers as a convenience measure; it is convenient
to be able to run the same binary with any kernel and for a user to be
able to compile your application no matter if he has a full kernel
source installed or if he is running a different kernel version or not.
They are not intended to be an annoyance or source of confusion (though
they are frequently perceived as such by people who misunderstand the
intent).  It is fortunate that the bad old days of /usr/include/linux ->
/usr/src/linux/include are mostly gone, but some systems still do that
anyway (Slackware?).

-- 
Ryan Underwood, <nemesis@icequake.net>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]