public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
To: "Dana Lacoste" <dana.lacoste@peregrine.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re:       [OT] Re: Linus's include file strategy redux
Date: Fri, 15 Dec 2000 17:09:57 MET-1	[thread overview]
Message-ID: <FBFCEB5345D@vcnet.vc.cvut.cz> (raw)

On 15 Dec 00 at 11:00, Dana Lacoste wrote:
> > Maybe you did not notice, but for months we have
> > /lib/modules/`uname -r`/build/include, which points to kernel headers,
> > and which should be used for compiling out-of-tree kernel modules
> > (i.e. latest vmware uses this).
> 
> What about the case where I'm compiling for a kernel that I'm
> not running (yet)?
> 
> lm_sensors, for example, told me yesterday when I compiled it
> that I was running 2.2.17, but it was compiling for 2.2.18
> (because I moved the symlink in /usr/src/linux to point to
> /usr/src/linux-2.2.18)
> 
> I personally wouldn't like some programs to do a `uname -r`
> check because it won't do what I want it to :)

You can list /lib/modules/*/build/include and present user with list
of possible kernels. You should check whether version.h contents
matches directory name, but it is just an additional check against 
users which compile all kernels in /usr/src/linux.

For lmsensors, you just have to compile kernel first, and lm_sensors
after that. But intervening reboot is not required as long as
configure does not use 'uname -r' (ok, I'm filling vmware bugreport
just now).
                            Best regards,
                                    Petr Vandrovec
                                    vandrove@vc.cvut.cz
                                    
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

             reply	other threads:[~2000-12-15 16:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-15 17:09 Petr Vandrovec [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-12-15 16:56 [OT] Re: Linus's include file strategy redux Petr Vandrovec
2000-12-15 16:00 ` Dana Lacoste
2000-12-15 16:16   ` Eli Carter
2000-12-15 17:31 ` ferret
2000-12-15 18:56   ` Ingo Oeser
2000-12-16  3:37     ` ferret
2000-12-16  6:57       ` Keith Owens
2000-12-16 16:40         ` ferret
2000-12-16 23:43       ` Peter Samuelson
2000-12-17  3:05         ` ferret
2000-12-17  8:08           ` Peter Samuelson
2000-12-17 20:08             ` ferret
2000-12-18  3:58               ` Peter Samuelson
2000-12-18 19:21                 ` ferret

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=FBFCEB5345D@vcnet.vc.cvut.cz \
    --to=vandrove@vc.cvut.cz \
    --cc=dana.lacoste@peregrine.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox