I would like to take this even further, when you install a third party
driver, vmware's
modules for example. they:
-install their src in: /usr/src/drivers/vmware
-compile it against the current kernel, assuming that the headers from
the running kernel are
always in /usr/src/linux-version and if that doesn't exist in
/usr/src/linux, and install the
module(s).
-whenever I compile a new kernel, it knows about the /usr/src/drivers
hierarchy, and
when I do make modules, it does a make modules in all it's subdirs, so
that the third-party
drivers for the new kernel get buidl automaticly. This of course
requires the passing of
some info about the new kernel, but that should be doable. Dito for
make modules_install.
-whenever I install a new kernel package (rpm or deb) the rpm also knows
about the
/usr/src/drivers hiearchy and rebuilds them too.
This is just an idea, not the solution. But I think the solution should
be something amongst the lines of driver-packages with some special
info, which are:
-automaticly build on install, keeping the sources somehwere for later
kernel installs.
-automaticly rebuild on a kenrel compile
-automaticly rebuild upon a kernel install from a package
If we could come up with a standard for this, this would be a tremendous
help for a lott of drivers, even for binary one's since they could come
up with their own abstraction layer which
is rebuild every time, keeping the binary part the same (like oss does,
and the disk on chip driver form m-sys too.) This standard should be
distribution and platform independent!
This way we have the best of both worlds, no binary compatibility to
maintain and (allmost) transparant support to the end user.
I'm willing to spend time on this idea, if I get backing for the concept
from enough people to know that it will actually be used in the long run
( Alan? ).
Regards,
Hans
p.s.
Please cc me I'm not on linux-kernel, although I do read the web
archives from time to time.
-
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/