>> It is the only thing that work, real life has proven that.
Donald> I'm sorry, I don't intend to flame, but I really do believe
Donald> this is bunk. I spent more than a minute considering if I
Donald> should respond or not, and I really needed to say it. I think
Donald> the current model is exactly as David puts it, unscalable.
Donald> IMHO, something will give eventually. I also think Ted sees
Donald> this as a problem (considering his post), but I don't want to
Donald> put words in his mouth.
The current model is the only thing that works for the developers, yes
it may be inconvenient for the users to download the large tarball
with support for 10 different architectures to compile a kernel for
the x86. However the kernel source is to be managable for the
_developers_.
Donald> Ted suggests it to be a question of design, Alan at OLS
Donald> suggested API between sections _needs_ to be able to evolve.
Donald> Thus, the problem is real because design can't see into the
Donald> future and driver (or on our case, whole Board Support
Donald> Package) authors have to get on with life eventually.
The other issue, quoting Alan, is that a lot of drivers contain the
same bugs, if you nail a bug in one driver you are likely to be able
to fix it in 5 other drivers. If they are all seperated someone will
discover the same bug 12 months later/.
David> No one is going to want to hand propagate kernel API changes
David> through 1000 (or 5000) device drivers in the kernel tree just
David> to get a clean build, or even to wade through that many kernel
David> config options to find the ones they want.
Shell scripting fortunately solves most of that problem, and if I make
an API change to something, I consider it my responsibility to at
least try and propagate it to a large part of code in the tree. I
cannot be bothered to run around searching for obscure drivers on the
Web though.
Jes
-
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/