Re: toplevel Makefile bug and simple fix

Gerard Roudier (
Sat, 6 Nov 1999 18:26:35 +0100 (MET)

On Sun, 7 Nov 1999, Keith Owens wrote:

> On Sat, 6 Nov 1999 06:56:07 -0500,
> "Theodore Y. Ts'o" <> 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.
> Then the user just does "make bzlilo modules modules_install".

It is what I used to do between driver releases I send to kernel
mainstream and it leads to having to deal with zillions of patches.

Think to a situation where it would be possible to generically declare a
driver in a kernel, where driver code does not rely on kernel options and
where exported interface drivers have to use are clearly exported,
documented and support and change well announced.

There are still machines using 2.0.X kernels and that need up-to-date
drivers for the reason they run recent hardwares. You can't ensure a
single patch (or patch series) will be needed even for the 2 latest X.Y.Z
kernel versions since a Makefile or and friends addendum or
change may just break your patch (or patch series). Zillions of patches
and not less when using diffs against kernel sources if you really want to
distribute drivers this way to most of users that need driver updates.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at