public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: "Nick Bartos" <spam99@2thebatcave.com>, linux-kernel@vger.kernel.org
Subject: Re: Using kernel headers that are not for the running kernel
Date: Sat, 19 Jun 2004 05:46:50 -0500	[thread overview]
Message-ID: <200406190546.50166.rob@landley.net> (raw)
In-Reply-To: <53712.192.168.1.12.1087514884.squirrel@192.168.1.12>

On Thursday 17 June 2004 18:28, Nick Bartos wrote:
> I have a little distro that I am trying to upgrade to 2.6.x.
>
> The problem is that when I use the headers for 2.6.x, glibc 2.2.5 won't
> compile.  Eventually I want to upgrade glibc/gcc, but not at the moment.
> If I use the headers from 2.4.26 for the system, but just compile the
> 2.6.7 kernel, things do compile fine for everything.

The linux-kernel maintainers apparently decided that C libraries using kernel 
headers to actually interface with the kernel was a bad idea.  Apparently, 
interfacing with the kernel from a C library is not a proper use for kernel 
headers, or something.  (I tried to follow the logic in this discussion, but 
never actually found any, despite repeated attempts.  It always seemed to 
boil down to "can't be bothered", "userspace shouldn't use kernel headers and 
this includes the C library", etc...)

On a pragmatic level, you want the cleaned up 2.6 kernel headers maintained by 
Mariusz Mazur <mmazur@kernel.pl> which you can download from:

http://ep09.pld-linux.org/~mmazur/linux-libc-headers/

> I see that a lot of distros use a separate package for the kernel headers,
> which do not necessarily coincide with the running kernel.

Yup.  It sucks, but there's no alternative for 2.6.

Mazur does a good job, though.

> I am wondering what (if any) are the side effects of doing this are,
> especially when the kernel versions are so different.

You're generally safe using older header versions.  (Heck, you can use 2.4 
headers to build your C library if you like.  The resulting C library just 
won't be able to use various new features like more than 256 minor numbers 
for devices, or possibly the ability to burn with ATA CD-ROM drives without 
SCSI emulation...)

> I was thinking that
> there may be issues with some progs if the prototypes for certain kernel
> functions weren't the same.  However people are doing it and it does seem
> to work, but I am wondering how it fends for stability.

If using old headers didn't work on new kernels then using old binaries 
wouldn't work on new kernels.  And that would be noticed big time.  (We can 
still run binaries that ran on Linux 0.01.  A couple minor things have been 
ripped out over the years, but not much.  The big backwards compatability 
issue is generally making sure you have the relevant old versions of the C 
library installed if you really want to run WordPerfect 6 or Netscape or 
such....)

Rob
-- 
www.linucon.org: Linux Expo and Science Fiction Convention
October 8-10, 2004 in Austin Texas.  (I'm the con chair.)


  parent reply	other threads:[~2004-06-20  8:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-17 23:28 Using kernel headers that are not for the running kernel Nick Bartos
2004-06-18  0:04 ` David Schwartz
2004-06-18 13:25   ` Krzysztof Halasa
2004-06-18  9:27 ` Jesper Juhl
2004-06-19 10:46 ` Rob Landley [this message]
2004-06-20 16:24   ` Jeff Garzik
2004-06-21  0:37     ` Rob Landley
2004-06-21 15:29       ` Randy.Dunlap

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=200406190546.50166.rob@landley.net \
    --to=rob@landley.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spam99@2thebatcave.com \
    /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