lkml.org 
[lkml]   [1999]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: toplevel Makefile bug and simple fix
On Sun, 7 Nov 1999, Keith Owens wrote:

> On Sat, 6 Nov 1999 06:56:07 -0500,
> "Theodore Y. Ts'o" <tytso@mit.edu> wrote:
> >P.S. And we really *have* to be able to support stand-alone source
> >distribution of drivers. The Linux kernel sources are still growing
> >expenontially, with a time constant of roughly 18 months. This is
> >mostly due to new drivers. Sooner or later, we will need to address the
> >question of how to distribute drivers independently of the kernel, in
> >source form at the very least.
>
> Cc:ed to linux-kbuild.
>
> Recommended solution - anybody distributing a driver independently of
> the kernel should ship a patch against the kernel source tree that
>
> (a) adds the files required by the driver
> (b) defines a Makefile fragment for the new driver, the fragment adds
> object names to the standard kernel Makefile variables.
>
We tried that. The completely stand-alone module model works
much more cleanly for maintenance and packaging purposes.

You need to update your packaging much more frequently when
you generate kernel patches, and more knowledge is required
of the current driver maintainer. Using a stand-alone module
means that your patch doesn't break, and the current driver
maintainer doesn't need to know as many details about the
kernel tree structure as he would if he needed to patch against it.

It also means that the user does "rpm -i package" or "dpkg -i package",
it builds itself, and it is simply a matter of starting it from there.

This does require a consistent state for kernel headers, and that
they be accessible by default.

> Then the user just does "make bzlilo modules modules_install".
>
Unnecessary requirement on the user at install time.
This is a no-no for a commercial product.

> AFAICT this method (adding independent modules to the kernel Makefile
> tree) is the only way to guarantee that the module is compiled with the
> correct options. I have seen people try to copy kernel compile options
> by hand into a separate source tree and get them wrong, in particular
> they get genksyms wrong most of the time. Also most separate compiles
> completely omit dependency checking. Using the kernel makefile
> structure gets it right every time.
>
I have never had genksyms work right within the kernel.
So I don't touch the things if I can avoid it. I have
noticed that most of the distributions don't use them
either. I'm sure that I am just missing something...


--
Daniel Taylor Senior Test Engineer Digi International
danielt@digi.com Open systems win.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.098 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site