All of lore.kernel.org
 help / color / mirror / Atom feed
From: DervishD <raul@pleyades.net>
To: "Richard B. Johnson" <root@chaos.analogic.com>
Cc: Matthew Reppert <repp0017@tc.umn.edu>,
	Lev Lvovsky <lists1@sonous.com>,
	linux-kernel@vger.kernel.org
Subject: Re: older kernels + new glibc?
Date: Tue, 30 Mar 2004 19:10:24 +0200	[thread overview]
Message-ID: <20040330171024.GT8304@DervishD> (raw)
In-Reply-To: <Pine.LNX.4.53.0403301001090.6371@chaos>

    Hi Richard :)

 * Richard B. Johnson <root@chaos.analogic.com> 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/

  reply	other threads:[~2004-03-30 17:15 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-29 20:40 older kernels + new glibc? Lev Lvovsky
2004-03-29 21:00 ` Arjan van de Ven
2004-03-29 21:09   ` Lev Lvovsky
2004-03-29 21:22     ` Arjan van de Ven
2004-03-29 21:26       ` Lev Lvovsky
2004-03-29 21:28         ` Arjan van de Ven
2004-03-29 21:34           ` Lev Lvovsky
2004-03-29 21:36             ` Arjan van de Ven
2004-03-29 21:45             ` Chris Meadors
2004-03-29 23:03             ` David T Hollis
2004-03-30 15:07       ` Adrian Bunk
2004-03-31  0:54         ` GOTO Masanori
2004-03-29 21:17 ` Richard B. Johnson
2004-03-29 21:36   ` Lev Lvovsky
2004-03-29 21:50     ` Richard B. Johnson
2004-03-29 21:55       ` Lev Lvovsky
2004-03-29 22:10         ` Richard B. Johnson
2004-03-29 22:55           ` Lev Lvovsky
2004-03-30 12:19             ` Richard B. Johnson
2004-03-29 22:27   ` DervishD
2004-03-29 23:55     ` Matthew Reppert
2004-03-30  0:09       ` Lev Lvovsky
2004-03-30 14:50       ` DervishD
2004-03-30 15:15         ` Richard B. Johnson
2004-03-30 17:10           ` DervishD [this message]
2004-03-30 12:16     ` Richard B. Johnson
2004-03-30 15:20       ` DervishD

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=20040330171024.GT8304@DervishD \
    --to=raul@pleyades.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lists1@sonous.com \
    --cc=repp0017@tc.umn.edu \
    --cc=root@chaos.analogic.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 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.