>David> The strategy of putting all device drivers in the kernel tree
>David> is fundamentally unscalable.
Yes, absolutely. From my point of view, the guy who buys RedHat at
Chapters could care less about drivers that work for something he
does not have, much less our stuff for some obscure (for him anyway)
driver for a microcontroller serial port. But I still need to keep that
driver to be up to date, along with piles of weird drivers for boards I
don't even have compilers for!
>It is the only thing that work, real life has proven that.
I'm sorry, I don't intend to flame, but I really do believe this is bunk.
I spent more than a minute considering if I should respond or not, and I
really needed to say it. I think the current model is exactly as David
puts it, unscalable. IMHO, something will give eventually. I also think
Ted sees this as a problem (considering his post), but I don't want to put
words in his mouth.
Mind you, I have no sol'n to offer. Once a maintainer moves on (and it's when,
not if) if the driver is not in the tree, you're out of luck when the kernel
drifts. Therefore, even for obscure hardware I try to pull everything back
into the main uClinux tree. And up to now I fail miserably, with only
4 uClinux ports integrated. If it's not in the main tree development just
diverges and diverges until it looks like way too much damn work.
Ted suggests it to be a question of design, Alan at OLS suggested API
between sections _needs_ to be able to evolve. Thus, the problem is real
because design can't see into the future and driver (or on our case, whole
Board Support Package) authors have to get on with life eventually.
>David> No one is going to want to hand propagate kernel API
>David> changes through 1000 (or 5000) device drivers in the kernel
>David> tree just to get a clean build, or even to wade through that
>David> many kernel config options to find the ones they want.
>Thats what tools like perl and sed were invented for.
I really don't see how solving a subset of the problem this way does anything
but point out how unscalable the situation is as soon as an API change breaks
something you _have_ to fix by hand.
-- Cheers, Jeff / VE3DJF Jeff@RyeHam.ee.ryerson.ca- 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/