Hello,
I'm not sure what, if any interrelations there are between the various
versions of glibc, and the kernel.
Specifically, a piece of telecom hardware that we use out in the field
requires a 2.2.x kernel to compile the drivers, however, after choosing
an arbitrary "new" release of a linux distro, and downgrading the
kernel, we are able to compile and install the drivers, and
subsequently use the hardware.
Are there any URLs/Docs that I could look at to understand what, if any
relationships glibc, and the kernel have?
thank you!
-lev
> Specifically, a piece of telecom hardware that we use out in the field
> requires a 2.2.x kernel to compile the drivers, however, after choosing
you could of course ask/use the source of the driver and port it to
2.4... that's what open source is about ;)
We have the source of the drivers, but they are specific to the 2.2.x
kernels. I am not a kernel hacker, and this would be way beyond my
area of expertise.
And sadly, this doesn't answer the initial question.
-lev
On Mar 29, 2004, at 1:00 PM, Arjan van de Ven wrote:
>
>> Specifically, a piece of telecom hardware that we use out in the field
>> requires a 2.2.x kernel to compile the drivers, however, after
>> choosing
>
> you could of course ask/use the source of the driver and port it to
> 2.4... that's what open source is about ;)
On Mon, 29 Mar 2004, Lev Lvovsky wrote:
> Hello,
>
> I'm not sure what, if any interrelations there are between the various
> versions of glibc, and the kernel.
>
> Specifically, a piece of telecom hardware that we use out in the field
> requires a 2.2.x kernel to compile the drivers, however, after choosing
> an arbitrary "new" release of a linux distro, and downgrading the
> kernel, we are able to compile and install the drivers, and
> subsequently use the hardware.
>
> Are there any URLs/Docs that I could look at to understand what, if any
> relationships glibc, and the kernel have?
>
> thank you!
> -lev
For glibc compatibility you need to get rid of the sym-link(s)
/usr/include/asm and /usr/include/linux in older distributions.
You need to replace those with headers copied from the kernel
in use when the C runtime library was compiled. If you can't find
those, you can either upgrade your C runtime library, or copy
headers from some older kernel that was known to work.
In any event, you need to remove the sym-link that ends up
pointing to your 'latest and greatest' kernel.
If you do this, you should find no incompatibilities between
user-mode code and any (within reason, 0.99 might not work)
kernel version.
Drivers are a different problem. There is no possibility
of just compiling old drivers and having them work. Drivers
need to be modified for each kernel version major version
number and, sometimes, even minor version numbers.
Sometimes you are lucky, usually not. Modules written for
2.4.x will not compile on 2.6.x and there is no compatibility
layer to accommodate. You need to look at how new modules are
written for a new version and modify your module code
accordingly. One can usually just compile and then 'fix' the
resulting errors. However, this might not produce a working
driver because some functions you count on might not exist
anymore. It compiles fine, but won't install.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Mon, 2004-03-29 at 23:09, Lev Lvovsky wrote:
> We have the source of the drivers, but they are specific to the 2.2.x
> kernels. I am not a kernel hacker, and this would be way beyond my
> area of expertise.
>
> And sadly, this doesn't answer the initial question.
then to answer your question; at compile time you tell glibc what
minimum kernel version it can assume, and based on that glibc will
enable/disable certain features. So it depends on what your distro
supplied there if it'll work or not. if you tell glibc that at minimum
you do 2.4.1 for example, then no a 2.2 kernel won't work. I think most
distros do this (or an even later version) since a few years now.
On Mar 29, 2004, at 1:22 PM, Arjan van de Ven wrote:
> On Mon, 2004-03-29 at 23:09, Lev Lvovsky wrote:
>> We have the source of the drivers, but they are specific to the 2.2.x
>> kernels. I am not a kernel hacker, and this would be way beyond my
>> area of expertise.
>>
>> And sadly, this doesn't answer the initial question.
>
> then to answer your question; at compile time you tell glibc what
> minimum kernel version it can assume, and based on that glibc will
> enable/disable certain features. So it depends on what your distro
> supplied there if it'll work or not. if you tell glibc that at minimum
> you do 2.4.1 for example, then no a 2.2 kernel won't work. I think most
> distros do this (or an even later version) since a few years now.
perfect - where does this variable get set? sorry for what now seems
like OT glibc stuff.
thanks,
-lev
On Mon, Mar 29, 2004 at 01:26:00PM -0800, Lev Lvovsky wrote:
> On Mar 29, 2004, at 1:22 PM, Arjan van de Ven wrote:
>
> >On Mon, 2004-03-29 at 23:09, Lev Lvovsky wrote:
> >>We have the source of the drivers, but they are specific to the 2.2.x
> >>kernels. I am not a kernel hacker, and this would be way beyond my
> >>area of expertise.
> >>
> >>And sadly, this doesn't answer the initial question.
> >
> >then to answer your question; at compile time you tell glibc what
> >minimum kernel version it can assume, and based on that glibc will
> >enable/disable certain features. So it depends on what your distro
> >supplied there if it'll work or not. if you tell glibc that at minimum
> >you do 2.4.1 for example, then no a 2.2 kernel won't work. I think most
> >distros do this (or an even later version) since a few years now.
>
> perfect - where does this variable get set? sorry for what now seems
> like OT glibc stuff.
it's passed to glibc ./configure at build time; if you have an rpm based
distro you'll see it in the specfile of the src.rpm
On Mar 29, 2004, at 1:28 PM, Arjan van de Ven wrote:
>> perfect - where does this variable get set? sorry for what now seems
>> like OT glibc stuff.
>
> it's passed to glibc ./configure at build time; if you have an rpm
> based
> distro you'll see it in the specfile of the src.rpm
ok, so this presents a bit of a problem in that case (assuming I'm
understanding you) - I'm working backwards in this respect, as I'm
using the "new" version of glibc, and an older version of the kernel
than the one that glibc was told to remain compatible with - the
important question, is does this order of operations (possibly) break
things, or does the fact that I compiled the kernel on this new version
of glibc remove any issues.
thanks,
-lev
On Mar 29, 2004, at 1:17 PM, Richard B. Johnson wrote:
> For glibc compatibility you need to get rid of the sym-link(s)
> /usr/include/asm and /usr/include/linux in older distributions.
> You need to replace those with headers copied from the kernel
> in use when the C runtime library was compiled. If you can't find
> those, you can either upgrade your C runtime library, or copy
> headers from some older kernel that was known to work.
I might be a bit confused here, but the problem with that, is that I'm
effectively working backwards. I've reverted the kernel version, but
all other applications have been kept of course - this means that
though I can keep those sym-links pointing to the correct kernel
headers (those which were present when glibc was compiled), the current
kernel (the reverted one) will obviously have different include files.
In order to compile the modules for the afformentioned hardware, those
symlinks need to point to the 2.2.x kernel directories - will this
break functionality of future compiled applications etc?
> Drivers are a different problem. There is no possibility
> of just compiling old drivers and having them work. Drivers
> need to be modified for each kernel version major version
> number and, sometimes, even minor version numbers.
right - luckily, at least so far, the modules and the applications that
we have built for the hardware works on the newer (minor version update
2.2.14 -> 2.2.26) kernel.
thanks,
-lev
On Mon, Mar 29, 2004 at 01:34:23PM -0800, Lev Lvovsky wrote:
>
> On Mar 29, 2004, at 1:28 PM, Arjan van de Ven wrote:
> >>perfect - where does this variable get set? sorry for what now seems
> >>like OT glibc stuff.
> >
> >it's passed to glibc ./configure at build time; if you have an rpm
> >based
> >distro you'll see it in the specfile of the src.rpm
>
> ok, so this presents a bit of a problem in that case (assuming I'm
> understanding you) - I'm working backwards in this respect, as I'm
> using the "new" version of glibc, and an older version of the kernel
> than the one that glibc was told to remain compatible with - the
> important question, is does this order of operations (possibly) break
> things, or does the fact that I compiled the kernel on this new version
> of glibc remove any issues.
glibc will just plain refuse to operate (correctly). glibc makes assumptions
about not needing workarounds for older kernels if you tell it it can assume
a newer kernel...
On Mon, 2004-03-29 at 13:34 -0800, Lev Lvovsky wrote:
> ok, so this presents a bit of a problem in that case (assuming I'm
> understanding you) - I'm working backwards in this respect, as I'm
> using the "new" version of glibc, and an older version of the kernel
> than the one that glibc was told to remain compatible with - the
> important question, is does this order of operations (possibly) break
> things, or does the fact that I compiled the kernel on this new version
> of glibc remove any issues.
It does not remove any issues. The kernel doesn't care what libc you
are running, it doesn't make use of the C libraries at all. But as you
have discovered the libc can be told to care a great deal about the
kernel on which it is running.
--
Chris
On Mon, 29 Mar 2004, Lev Lvovsky wrote:
>
> On Mar 29, 2004, at 1:17 PM, Richard B. Johnson wrote:
>
> > For glibc compatibility you need to get rid of the sym-link(s)
> > /usr/include/asm and /usr/include/linux in older distributions.
> > You need to replace those with headers copied from the kernel
> > in use when the C runtime library was compiled. If you can't find
> > those, you can either upgrade your C runtime library, or copy
> > headers from some older kernel that was known to work.
>
> I might be a bit confused here, but the problem with that, is that I'm
> effectively working backwards. I've reverted the kernel version, but
> all other applications have been kept of course - this means that
> though I can keep those sym-links pointing to the correct kernel
> headers (those which were present when glibc was compiled), the current
> kernel (the reverted one) will obviously have different include files.
>
> In order to compile the modules for the afformentioned hardware, those
> symlinks need to point to the 2.2.x kernel directories - will this
> break functionality of future compiled applications etc?
>
No No. Never! The modules never, ever, use glibc headers. Never!
The compilation should set the -I (include) parameter to point
to the kernel headers.
Something like:
VER := $(shell uname -r)
INC= -I. -I/usr/src/linux-$(VER)
DEF= -D__KERNEL__ -DMODULE
gcc -c -Wall -O2 -fomit-frame-pointer $(INC) $(DEF) -m module.o module.c
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Mar 29, 2004, at 1:50 PM, Richard B. Johnson wrote:
> On Mon, 29 Mar 2004, Lev Lvovsky wrote:
>> I might be a bit confused here, but the problem with that, is that I'm
>> effectively working backwards. I've reverted the kernel version, but
>> all other applications have been kept of course - this means that
>> though I can keep those sym-links pointing to the correct kernel
>> headers (those which were present when glibc was compiled), the
>> current
>> kernel (the reverted one) will obviously have different include files.
>>
>> In order to compile the modules for the afformentioned hardware, those
>> symlinks need to point to the 2.2.x kernel directories - will this
>> break functionality of future compiled applications etc?
>>
>
> No No. Never! The modules never, ever, use glibc headers. Never!
>
> The compilation should set the -I (include) parameter to point
> to the kernel headers.
>
> Something like:
>
> VER := $(shell uname -r)
> INC= -I. -I/usr/src/linux-$(VER)
> DEF= -D__KERNEL__ -DMODULE
>
> gcc -c -Wall -O2 -fomit-frame-pointer $(INC) $(DEF) -m module.o
> module.c
sorry, that was my mistake in wording - the modules point to the kernel
headers. However, the system as it was first made, had those
directories symlinked to the 2.4.7 (?) kernel - I had to remove that
package, and symlink the "asm", and "linux" directories to the 2.2.26
kernel directories of the same name - I'm assuming this is the correct
thing to do? (it did work ;)
thanks,
-lev
On Mon, 29 Mar 2004, Lev Lvovsky wrote:
>
> On Mar 29, 2004, at 1:50 PM, Richard B. Johnson wrote:
>
> > On Mon, 29 Mar 2004, Lev Lvovsky wrote:
> >> I might be a bit confused here, but the problem with that, is that I'm
> >> effectively working backwards. I've reverted the kernel version, but
> >> all other applications have been kept of course - this means that
> >> though I can keep those sym-links pointing to the correct kernel
> >> headers (those which were present when glibc was compiled), the
> >> current
> >> kernel (the reverted one) will obviously have different include files.
> >>
> >> In order to compile the modules for the afformentioned hardware, those
> >> symlinks need to point to the 2.2.x kernel directories - will this
> >> break functionality of future compiled applications etc?
> >>
> >
> > No No. Never! The modules never, ever, use glibc headers. Never!
> >
> > The compilation should set the -I (include) parameter to point
> > to the kernel headers.
> >
> > Something like:
> >
> > VER := $(shell uname -r)
> > INC= -I. -I/usr/src/linux-$(VER)
> > DEF= -D__KERNEL__ -DMODULE
> >
> > gcc -c -Wall -O2 -fomit-frame-pointer $(INC) $(DEF) -m module.o
> > module.c
>
> sorry, that was my mistake in wording - the modules point to the kernel
> headers. However, the system as it was first made, had those
> directories symlinked to the 2.4.7 (?) kernel - I had to remove that
> package, and symlink the "asm", and "linux" directories to the 2.2.26
> kernel directories of the same name - I'm assuming this is the correct
> thing to do? (it did work ;)
>
You didn't care to read what I said? I said to remove those sym-links.
They must be replaced by headers that were in-use around the time
the C library code was compiled, preferably the exact same headers.
There must not be any sym-link in the /usr/include/... directories
pointing to any kernel headers. That way, you can add new kernels
without ever screwing up your compiler.
When you compile modules, NO 'C' runtime library components are
used at except, possibly, stddef.h or stdarg.h. These are
automatically searched in the `gcc -print-file-name=include`
directory. You can see what's there by executing:
ls `gcc -print-file-name=include`. You can guarantee that
only the files you want are searched by using -nostdinc on
the gcc command line. Of course if you do this, stddef.h
won't be found, if needed so you would need to add the
that directory back to the search-list.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Hi Richard :)
* Richard B. Johnson <[email protected]> dixit:
> For glibc compatibility you need to get rid of the sym-link(s)
> /usr/include/asm and /usr/include/linux in older distributions.
> You need to replace those with headers copied from the kernel
> in use when the C runtime library was compiled. If you can't find
> those, you can either upgrade your C runtime library, or copy
> headers from some older kernel that was known to work.
> In any event, you need to remove the sym-link that ends up
> pointing to your 'latest and greatest' kernel.
Mmm, I'm confused. As far as I knew, you *should* use symlinks to
your current (running) kernel includes for /usr/include/asm and
/usr/include/linux. I've been doing this for years (in fact I
compiled my libc back in the 2.2 days IIRC), without problems. Why it
should be avoided and what kind of problems may arise if someone
(like me) has those symlinks?
User space programs should not use kernel headers, so this
shouldn't be a problem, and kernel related tools should use the
headers from the current (running) kernel or a similar version (here
'similar' as a broad meaning, I think, let's say that it means 'same
series as the running kernel, but newer), but I'm afraid I'm missing
something...
Thanks in advance :)
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/
On Mar 29, 2004, at 2:10 PM, Richard B. Johnson wrote:
> You didn't care to read what I said? I said to remove those sym-links.
> They must be replaced by headers that were in-use around the time
> the C library code was compiled, preferably the exact same headers.
>
> There must not be any sym-link in the /usr/include/... directories
> pointing to any kernel headers. That way, you can add new kernels
> without ever screwing up your compiler.
Understood. Incidentally, the glibc-kernheaders package included with
RH 7.3 creates those files as symlinks, I'm sure however that they were
there for the compilation of glibc. The disconnect that I forsee, is
that I will be running the 2.2.26 with kernel headers from a 2.4.x
kernel - would this be the correct thing to do?
I suppose I mirror the sentiments of DervishD on this from his post.
-lev
On Mon, 2004-03-29 at 13:34 -0800, Lev Lvovsky wrote:
> On Mar 29, 2004, at 1:28 PM, Arjan van de Ven wrote:
> >> perfect - where does this variable get set? sorry for what now seems
> >> like OT glibc stuff.
> >
> > it's passed to glibc ./configure at build time; if you have an rpm
> > based
> > distro you'll see it in the specfile of the src.rpm
>
> ok, so this presents a bit of a problem in that case (assuming I'm
> understanding you) - I'm working backwards in this respect, as I'm
> using the "new" version of glibc, and an older version of the kernel
> than the one that glibc was told to remain compatible with - the
> important question, is does this order of operations (possibly) break
> things, or does the fact that I compiled the kernel on this new version
> of glibc remove any issues.
>
> thanks,
> -lev
>
> -
In looking at the latest and greatest glibc spec file for Fedora, it
appears that on x86 architectures, glibc is built to support all the way
down to 2.2.5. On 64 bit arches, its set for various 2.4 kernels. If
you are using Red Hat or Fedora, you will probably be ok. Any other
distro and I can't help you there. If it is just these drivers that are
holding you to 2.2, you can certainly find folks willing to port them to
2.4 or 2.6 for a reasonable fee that is quite certainly less than the
amount of man hours you will spend trying to get this house of cards
together. Depending on what the drivers do and how they are written, it
may be trivial or it may be quite involved.
--
David T Hollis <[email protected]>
On Mon, 2004-03-29 at 16:27, DervishD wrote:
> Hi Richard :)
>
> * Richard B. Johnson <[email protected]> dixit:
> > For glibc compatibility you need to get rid of the sym-link(s)
> > /usr/include/asm and /usr/include/linux in older distributions.
> > You need to replace those with headers copied from the kernel
> > in use when the C runtime library was compiled. If you can't find
> > those, you can either upgrade your C runtime library, or copy
> > headers from some older kernel that was known to work.
> > In any event, you need to remove the sym-link that ends up
> > pointing to your 'latest and greatest' kernel.
>
> Mmm, I'm confused. As far as I knew, you *should* use symlinks to
> your current (running) kernel includes for /usr/include/asm and
> /usr/include/linux. I've been doing this for years (in fact I
> compiled my libc back in the 2.2 days IIRC), without problems. Why it
> should be avoided and what kind of problems may arise if someone
> (like me) has those symlinks?
See http://www.kernelnewbies.org/faq/index.php3#headers
The correct place, I've read, to get the headers for the current running
kernel is /lib/modules/$(uname -r)/build/include ... which of course
assumes that you keep your kernel in the same place you built it from,
but that's not a worse assumption than whatever you'd assume for
/usr/include/{linux,asm} symlinks to work I'm sure.
Basically, the potential problem as I understand it is binary
incompatibility with the currently installed glibc.
Matt
On Mar 29, 2004, at 3:55 PM, Matthew Reppert wrote:
>
> See http://www.kernelnewbies.org/faq/index.php3#headers
>
> The correct place, I've read, to get the headers for the current
> running
> kernel is /lib/modules/$(uname -r)/build/include ... which of course
> assumes that you keep your kernel in the same place you built it from,
> but that's not a worse assumption than whatever you'd assume for
> /usr/include/{linux,asm} symlinks to work I'm sure.
>
> Basically, the potential problem as I understand it is binary
> incompatibility with the currently installed glibc.
>
> Matt
http://www.ussg.iu.edu/hypermail/linux/kernel/0007.3/0587.html
beautiful, this answers all questions :)
thanks everyone!
-lev
On Tue, 30 Mar 2004, DervishD wrote:
> Hi Richard :)
>
> * Richard B. Johnson <[email protected]> dixit:
> > For glibc compatibility you need to get rid of the sym-link(s)
> > /usr/include/asm and /usr/include/linux in older distributions.
> > You need to replace those with headers copied from the kernel
> > in use when the C runtime library was compiled. If you can't find
> > those, you can either upgrade your C runtime library, or copy
> > headers from some older kernel that was known to work.
> > In any event, you need to remove the sym-link that ends up
> > pointing to your 'latest and greatest' kernel.
>
> Mmm, I'm confused. As far as I knew, you *should* use symlinks to
> your current (running) kernel includes for /usr/include/asm and
> /usr/include/linux. I've been doing this for years (in fact I
> compiled my libc back in the 2.2 days IIRC), without problems. Why it
> should be avoided and what kind of problems may arise if someone
> (like me) has those symlinks?
>
The libc headers end up including kernel headers via the sym-links.
They must *only* use the headers with which libc was built. Therefore,
any sym-links should be removed and replaced with a copy of the
appropriate headers.
> User space programs should not use kernel headers, so this
> shouldn't be a problem, and kernel related tools should use the
> headers from the current (running) kernel or a similar version (here
> 'similar' as a broad meaning, I think, let's say that it means 'same
> series as the running kernel, but newer), but I'm afraid I'm missing
> something...
>
> Thanks in advance :)
Again, the C-library was built to work with certain structures
(for instance) that existed at the time it was built. Let's say
I use /usr/include/sys/stat.h to get the structure members of
'struct stat'. If I use the headers that existed at the time the
C library was built, all is fine. If I use the kernel headers
that exist now, the offsets may be incorrect because there have
may have been members added to that structure.
This comes about because the C library used kernel headers,
which it shouldn't have done in the first place.
FYI, you __never__ include C library headers when building
any kernel modules.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Mon, 29 Mar 2004, Lev Lvovsky wrote:
>
> On Mar 29, 2004, at 2:10 PM, Richard B. Johnson wrote:
> > You didn't care to read what I said? I said to remove those sym-links.
> > They must be replaced by headers that were in-use around the time
> > the C library code was compiled, preferably the exact same headers.
> >
> > There must not be any sym-link in the /usr/include/... directories
> > pointing to any kernel headers. That way, you can add new kernels
> > without ever screwing up your compiler.
>
> Understood. Incidentally, the glibc-kernheaders package included with
> RH 7.3 creates those files as symlinks, I'm sure however that they were
> there for the compilation of glibc. The disconnect that I forsee, is
> that I will be running the 2.2.26 with kernel headers from a 2.4.x
> kernel - would this be the correct thing to do?
To be absolutely sure you don't end up making user-mode code that
doesn't work, I would remove those sym-links and replace them with
the actual headers that are known to work.
>
> I suppose I mirror the sentiments of DervishD on this from his post.
>
> -lev
>
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Hi Matthew :)
* Matthew Reppert <[email protected]> dixit:
> > Mmm, I'm confused. As far as I knew, you *should* use symlinks to
> > your current (running) kernel includes for /usr/include/asm and
> > /usr/include/linux. I've been doing this for years (in fact I
> > compiled my libc back in the 2.2 days IIRC), without problems. Why it
> > should be avoided and what kind of problems may arise if someone
> > (like me) has those symlinks?
> See http://www.kernelnewbies.org/faq/index.php3#headers
Thanks a lot for the information, it's been quite useful :)))
I find the explanation extremely sensible, but the problem I see
is that some user-space tools that are very coupled with the kernel
(for example, hdparm) assume that the kernel headers can be accessed
throuhg a system standard include directory (like /usr/include). What
I mean is that all these tools just #include <linux/whatever.h>,
without making assumptions about where are they.
If I've understood correctly, these tools (like hdparm) should
*not* use current (running) kernel headers, but those that were in
use when glibc was built, am I right? Which, BTW, is a big problem
because I don't have the slightest idea about which kernel was in use
when I built my glibc.
But putting under /usr/include/linux and /usr/include/asm the
headers in use when glibc is built can lead to a problem, too.
Imagine that at some point in the future, the contents of the asm or
linux dirs depends on which facilities the kernel has configured
e.g. no scsi.h if no scsi support is present in the configured
kernel. That way, you don't have scsi.h under your
/usr/include/linux, but you may need it if you add an SCSI card with
your running kernel and want to compile some 'scsiutils' or whatever
like that.
I confess that this is a very weird scenario, very difficult to
appear but... Just wondering.
> The correct place, I've read, to get the headers for the current running
> kernel is /lib/modules/$(uname -r)/build/include
Please correct me if I'm wrong: only external kernel modules
should use current (running, again) kernel headers, no?
> Basically, the potential problem as I understand it is binary
> incompatibility with the currently installed glibc.
That has never happened to me, but reading Linus' explanation,
that can bite me in the future (if some interface I use in userspace
changes in the kernel).
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/
On Mon, Mar 29, 2004 at 11:22:24PM +0200, Arjan van de Ven wrote:
>...
> supplied there if it'll work or not. if you tell glibc that at minimum
> you do 2.4.1 for example, then no a 2.2 kernel won't work. I think most
> distros do this (or an even later version) since a few years now.
In Debian 3.0, it's set to kernel 2.2.
And it currently seems even the next stable release of Debian will have
it set to 2.2 on all architectures except sparc64 and s390x.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, 30 Mar 2004, DervishD wrote:
> Hi Matthew :)
>
> * Matthew Reppert <[email protected]> dixit:
> > > Mmm, I'm confused. As far as I knew, you *should* use symlinks to
> > > your current (running) kernel includes for /usr/include/asm and
> > > /usr/include/linux. I've been doing this for years (in fact I
> > > compiled my libc back in the 2.2 days IIRC), without problems. Why it
> > > should be avoided and what kind of problems may arise if someone
> > > (like me) has those symlinks?
> > See http://www.kernelnewbies.org/faq/index.php3#headers
>
> Thanks a lot for the information, it's been quite useful :)))
>
> I find the explanation extremely sensible, but the problem I see
> is that some user-space tools that are very coupled with the kernel
> (for example, hdparm) assume that the kernel headers can be accessed
> throuhg a system standard include directory (like /usr/include). What
> I mean is that all these tools just #include <linux/whatever.h>,
> without making assumptions about where are they.
>
If you have any user-mode 'kernel' utilities, you need to be
extremely careful because you can build code that doesn't work.
That's why you should use an 'include' search path on the
compiler command line when you are compiling these. The search
path should point to the kernel headers of the version you
intend to use. The kernel tries to remain compatible, but
when you access internal structures, compatibility may be lost.
> If I've understood correctly, these tools (like hdparm) should
> *not* use current (running) kernel headers, but those that were in
> use when glibc was built, am I right? Which, BTW, is a big problem
> because I don't have the slightest idea about which kernel was in use
> when I built my glibc.
>
Yes. One can usually 'trust' a distribution and use whatever they
shipped.
> But putting under /usr/include/linux and /usr/include/asm the
> headers in use when glibc is built can lead to a problem, too.
> Imagine that at some point in the future, the contents of the asm or
> linux dirs depends on which facilities the kernel has configured
> e.g. no scsi.h if no scsi support is present in the configured
> kernel. That way, you don't have scsi.h under your
> /usr/include/linux, but you may need it if you add an SCSI card with
> your running kernel and want to compile some 'scsiutils' or whatever
> like that.
>
No. User-mode programs must never, never, never, ever include
kernel headers directly. Instead, if they are for kernel utilities,
the include search-path must be explicitly set.
> I confess that this is a very weird scenario, very difficult to
> appear but... Just wondering.
>
> > The correct place, I've read, to get the headers for the current running
> > kernel is /lib/modules/$(uname -r)/build/include
>
This is one of the newer places that's been defined. It's probably
worthless because it's just another sim-link! And, it's a sim-link
to some kernel source that probably doesn't exist anymore. You
need to explicitly define where you want the include-search-path
to include when you compile kernel-specific things. In other words,
when compiling things that interface with the kernel or with
kernel internals, there is no free lunch. You need to know exactly
what you are doing.
> Please correct me if I'm wrong: only external kernel modules
> should use current (running, again) kernel headers, no?
>
Kernel modules must use the headers for the kernel version you
wish to run. That is not necessarily the kernel that is running
now. That's why you need to define the search-path for the
'include' files.
> > Basically, the potential problem as I understand it is binary
> > incompatibility with the currently installed glibc.
>
Yes. You need to keep user-space and kernel space seperate.
> That has never happened to me, but reading Linus' explanation,
> that can bite me in the future (if some interface I use in userspace
> changes in the kernel).
>
Correct.
> Ra?l N??ez de Arenas Coronado
>
> --
> Linux Registered User 88736
> http://www.pleyades.net & http://raul.pleyades.net/
>
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Hi Richard :)
* Richard B. Johnson <[email protected]> dixit:
> > Mmm, I'm confused. As far as I knew, you *should* use symlinks to
> > your current (running) kernel includes for /usr/include/asm and
> > /usr/include/linux. I've been doing this for years (in fact I
> > compiled my libc back in the 2.2 days IIRC), without problems. Why it
> > should be avoided and what kind of problems may arise if someone
> > (like me) has those symlinks?
> The libc headers end up including kernel headers via the sym-links.
> They must *only* use the headers with which libc was built. Therefore,
> any sym-links should be removed and replaced with a copy of the
> appropriate headers.
Looking at my backups of 2001 (god bless backups...) I found that
the running kernel when I built my glibc (yes, I still use the same
glibc that in 2001...) was 2.4.10, so I'm going to replace the
symlinks with two real dirs with the headers from 2.4.10. Thanks a
lot for your help :)
> This comes about because the C library used kernel headers,
> which it shouldn't have done in the first place.
Yes :(( I hope that in the next version that is fixed (and the
fact that the libc cannot be compiled with newer versions of GCC
because of an stupid bug in a prototype, but that's a very offtopic
matter...).
> FYI, you __never__ include C library headers when building
> any kernel modules.
If I ever write a kernel module, I won't ;) Thanks for your help
:)
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/
Hi Richard :)
* Richard B. Johnson <[email protected]> dixit:
[Kernel-related userspace tools]
> That's why you should use an 'include' search path on the
> compiler command line when you are compiling these. The search
> path should point to the kernel headers of the version you
> intend to use. The kernel tries to remain compatible, but
> when you access internal structures, compatibility may be lost.
So, as a rule of thumb, anytime I compile or install such
programs, I should set an include search path for them.
> > If I've understood correctly, these tools (like hdparm) should
> > *not* use current (running) kernel headers, but those that were in
> > use when glibc was built, am I right? Which, BTW, is a big problem
> > because I don't have the slightest idea about which kernel was in use
> > when I built my glibc.
> Yes. One can usually 'trust' a distribution and use whatever they
> shipped.
I don't use a distro, I have a do-it-yourself linux box, part of
it is from an old Debian 1.3.1, but most of it is hand-made. I
compile my own kernel-related tools. I suppose that, for each package
I install that may be kernel-related, I should do 'grep "<linux/"'
just in case...
> > But putting under /usr/include/linux and /usr/include/asm the
> > headers in use when glibc is built can lead to a problem, too.
> > Imagine that at some point in the future, the contents of the asm or
> > linux dirs depends on which facilities the kernel has configured
> > e.g. no scsi.h if no scsi support is present in the configured
> > kernel. That way, you don't have scsi.h under your
> > /usr/include/linux, but you may need it if you add an SCSI card with
> > your running kernel and want to compile some 'scsiutils' or whatever
> > like that.
> No. User-mode programs must never, never, never, ever include
> kernel headers directly. Instead, if they are for kernel utilities,
> the include search-path must be explicitly set.
Nice. But I don't feel it is current practice... For example,
hdparm doesn't set such include search path, iproute2 does but
modutils (up to 2.4.27, AFAIK) doesn't... I don't know many more
examples, so I may well be wrong.
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/
At Tue, 30 Mar 2004 17:07:20 +0200,
Adrian Bunk wrote:
> On Mon, Mar 29, 2004 at 11:22:24PM +0200, Arjan van de Ven wrote:
> >...
> > supplied there if it'll work or not. if you tell glibc that at minimum
> > you do 2.4.1 for example, then no a 2.2 kernel won't work. I think most
> > distros do this (or an even later version) since a few years now.
>
> In Debian 3.0, it's set to kernel 2.2.
FYI, it's set to 2.2 except for i386 and m68k (they are 2.0.30).
> And it currently seems even the next stable release of Debian will have
> it set to 2.2 on all architectures except sparc64 and s390x.
Plus i686.
Regards,
-- gotom