From: "J.A. Magallon" <firstname.lastname@example.org>
To: Arjan van de Ven <email@example.com>
Cc: "Heater, Daniel (IndSys, GEFanuc,
"'Linux Kernel Mailing List'" <firstname.lastname@example.org>
Subject: Re: Distributing drivers independent of the kernel source tree
Date: Fri, 27 Sep 2002 00:03:23 +0200 [thread overview]
Message-ID: <20020926220323.GA2773@werewolf.able.es> (raw)
In-Reply-To: <email@example.com>; from firstname.lastname@example.org on Thu, Sep 26, 2002 at 23:08:39 +0200
On 2002.09.26 Arjan van de Ven wrote:
>On Thu, 2002-09-26 at 22:55, Heater, Daniel (IndSys, GEFanuc, VMIC)
>> 2. Assuming the kernel source is in /usr/src/linux is not always valid.
>> 3. I currently use /usr/src/linux-`uname -r` to locate the kernel source
>> which is just as broken as method #2.
>you have to use
>(yes it's a symlink usually, but that doesn't matter)
>that's what Linus decreed and that's what all distributions honor, and
>that's that make install does for manual builds.
And that does not work if you build against a non-running kernel.
You force a two step (two reboots!!) procedure for a kernel upgrade.
Say I use alsa drivers. If I jump from kernel 2.4.18 to 2.4.19
I have to:
- build 2.4.19
- boot on 2.4.19 (without alsa and a ton of messages about failed
- build alsa
- boot again
I really hate that 'uname -r'. As far as /usr/src/linux has _nothing_
to do with current system (glibc has its own headers), you can always
suppose that /usr/src/linux is the source of the kernel you are working
with (building, hacking, wahtever), and that it is different from what
you run. So a kernel upgrade is just
- build 2.4.19 (on /usr/src/linux-2.4.19, and /usr/src/linux symlinks to it)
- build alsa against /usr/src/linux
- reboot and alehop, done in _one_ step.
Where to install the out-of-tree module ? Get the version you are building
against from /usr/src/linux/include/version.h:
KREL:=$(shell grep UTS_RELEASE /usr/src/linux/include/linux/version.h | cut -d\" -f2)
You can always not-to-hardcode kernel location using something like:
KREL=$(shell grep UTS_RELEASE $(LINUX)/include/linux/version.h | cut -d\" -f2)
I use this for adding nvidia and bproc to a kernel and works fine.
Just one reboot per upgrade.
J.A. Magallon <email@example.com> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.0 (Cooker) for i586
Linux 2.4.20-pre7-jam0 (gcc 3.2 (Mandrake Linux 9.0 3.2-1mdk))
next prev parent reply other threads:[~2002-09-26 21:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-26 20:55 Distributing drivers independent of the kernel source tree Heater, Daniel (IndSys, GEFanuc, VMIC)
2002-09-26 21:08 ` Arjan van de Ven
2002-09-26 21:41 ` Alan Cox
2002-09-26 21:48 ` Jeff Garzik
2002-09-26 22:03 ` J.A. Magallon [this message]
2002-09-27 12:40 ` jbradford
2002-09-27 12:48 ` Andreas Schwab
2002-09-27 13:08 ` jbradford
2002-09-30 21:35 ` Anders Gustafsson
2002-09-26 21:16 Heater, Daniel (IndSys, GEFanuc, VMIC)
2002-09-27 7:35 ` Arjan van de Ven
2002-09-26 21:55 Heater, Daniel (IndSys, GEFanuc, VMIC)
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).