>If your solution truly
>has any technical merit, then and only then when the code is
>written in reality, is it an issue at all.
.
.
.
>That is my point. Write the code, show what it does, and why it
>is the technically superior solution to the problem at hand, THEN
>submit it to linus, perhaps with some benchmarks.
>
>Then and only then will it become reality.
Although its hard to argue with the above, I will. The reluctance of
the kernel community to discuss (re)design issues in the absence of
working code can act as a brake on people actually coming up with
interesting new solutions.
Its true and fair and appropriate to say that Linux gets new code
because people write it for their own needs and whims. But if a piece
of code involves the guts of the kernel (say, the scheduler, or the
mm code) then hacking up one's own modifications to this without any
sense that the idea is likely to be accepted (even if *your* code is
not) implies a future of continually patching it into each subsequent
mainstream kernel that has desirable new features. patch(1) can help,
but not always.
I think that pushing for code is good, and keeps the "i want, i want,
i want" whining to a minimum. But there are times when I know *I* have
been reluctant to undertake work on deep kernel internals that I
*need* because I have no sense that there is any chance of the idea
being picked up *even if I write the code*. Since I don't want to have
to keep repatching through 2.3.whatever, I just make do. I doubt if I
am the only person to feel this way, and it seems like a small loss.
Perhaps fixing it would wipe out all the gains we get from the current
"no code - no comment" model. I don't know.
--p
-
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/