For some time I have been trying to figure out how to distribute drivers
that are not part of the kernel source tree. The drivers that I am supplying
are open source (BSD license) but are for obscure hardware and/or not ready
for/may never be ready for inclusion in the kernel proper. Business being
what it is though, I have to get them to the customer yesterday.
I would like to know if there is a good way to distribute drivers separate
from the kernel source tree?
1. Supplying patches does not seem to be feasible because there are so many
kernel versions and trees to cover. I'm not in a position to tell my
customers to run version 2.4.xx-xx. They need to be able to use these
drivers with the kernel version they have in their production environment.
Instead, I try to make my driver work on all versions of kernel 2.4.x.
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.
If no good method exists, would someone be willing to suggest a standard
which would allow distribution of drivers separate from the kernel tree?
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
/lib/modules/`uname -r`/build
(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.
Greetings,
Arjan van de Ven
That's true for installing modules, but I'm wondering about getting a
standalone module compiled. I.e., what is a reliable method for locating the
include files for the kernel?
I can find references on the web where this has been discussed in the past,
but I have not found a resolution.
> -----Original Message-----
> From: Arjan van de Ven [mailto:[email protected]]
> Sent: Thursday, September 26, 2002 4:09 PM
> To: Heater, Daniel (IndSys, ""GEFanuc, VMIC)
> Cc: 'Linux Kernel Mailing List'
> Subject: Re: Distributing drivers independent of the kernel
> source tree
>
>
> 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
>
> /lib/modules/`uname -r`/build
> (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.
>
> Greetings,
> Arjan van de Ven
>
On Thu, 2002-09-26 at 22:08, Arjan van de Ven wrote:
> you have to use
>
> /lib/modules/`uname -r`/build
> (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.
One additional item that may be useful, for Red Hat at least there is a
little kit to build additional driver disks.
Alan Cox wrote:
> One additional item that may be useful, for Red Hat at least there is a
> little kit to build additional driver disks.
...available at: http://people.redhat.com/dledford/
it's pretty neat...
>>/lib/modules/`uname -r`/build
>>(yes it's a symlink usually, but that doesn't matter)
> That's true for installing modules, but I'm wondering about getting a
> standalone module compiled. I.e., what is a reliable method
> for locating the
> include files for the kernel?
Doh!! Sorry Arjan, in haste, I misread your response. I get it now.
Thanks Arjan,
Thanks for pointing that out Tommy.
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
>
>/lib/modules/`uname -r`/build
>(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
sound services)
- 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:
LINUX=/usr/src/linux
KREL=$(shell grep UTS_RELEASE $(LINUX)/include/linux/version.h | cut -d\" -f2)
CFLAGS=-nostdinc -I$(LINUX)/include
MODDIR=/lib/modules/$(LINUX)/my_private_dir
I use this for adding nvidia and bproc to a kernel and works fine.
Just one reboot per upgrade.
/juan
--
J.A. Magallon <[email protected]> \ 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))
On Thu, Sep 26, 2002 at 05:16:03PM -0400, Heater, Daniel (IndSys, GEFanuc, VMIC) wrote:
>
> That's true for installing modules, but I'm wondering about getting a
> standalone module compiled. I.e., what is a reliable method for locating the
> include files for the kernel?
as I said
/lib/modules/`uname -r`/build/include
> > 2. Assuming the kernel source is in /usr/src/linux is not always valid.
> >=20
> > 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
>
> /lib/modules/`uname -r`/build
> (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.
What about instances where there is no modular support in the kernel? All of my main machines have loadable module support disabled... That seems to be a very rare configuration these days, but I prefer it.
John,
[email protected] writes:
|> > > 2. Assuming the kernel source is in /usr/src/linux is not always valid.
|> > >=20
|> > > 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
|> >
|> > /lib/modules/`uname -r`/build
|> > (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.
|>
|> What about instances where there is no modular support in the kernel?
If your kernel has no module support then you cannot compile kernel
modules.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
>
> [email protected] writes:
>
> |> > > 2. Assuming the kernel source is in /usr/src/linux is not always valid.
> |> > >=20
> |> > > 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
> |> >
> |> > /lib/modules/`uname -r`/build
> |> > (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.
> |>
> |> What about instances where there is no modular support in the kernel?
>
> If your kernel has no module support then you cannot compile kernel
> modules.
Sorry, my first post was a brain fart, I thought the original poster was talking about the correct way to identify the verison of source code that you're 'looking at'. Appologies for the wasted bandwidth.
John.
On Thu, Sep 26, 2002 at 04:55:07PM -0400, Heater, Daniel (IndSys, GEFanuc, VMIC) wrote:
> 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.
>
> If no good method exists, would someone be willing to suggest a standard
> which would allow distribution of drivers separate from the kernel tree?
In projects that use autoconf (ie, have a large userspace app) some people
might find this useful:
http://0x63.nu/files/kern-autoconf/
--
Anders Gustafsson - [email protected] - http://0x63.nu/