As it's not a driver I think I use, my opinions on the
matter should not carry any significant weight. On the
other hand, if there are no other opinions on the
matter, then no non-zero weight is insignificant.
(I'll leave it as an exercise to resolve the triple
Anyway, it is my opinion that code believed to be
dubious should be fixed and that it is an error to add
more code that carries the same potential flaw until
either the flaw is resolved or proven insignificant.
That includes flaws in style or code cleanliness.
If the flaw is easily fixed, then it would seem vastly
better to fix it once now rather than twice (or more)
later - particularly if there is any risk that copied
flaws could be forgotten. Forgotten temporary code is
an excellent breeding-ground for bugs.
There's also a potential for friction as there is a
very understandable unease when it comes to knowingly
adding brokenness to the mainstream kernel if it's not
necessary, again even if that isn't brokenness in
terms of logic but merely in some aspect of how it's
On the flip-side, if we waited for code to be perfect,
we'd still be waiting for Alan Turing to finish the
world's first stored program.
--- Thomas Koeller <firstname.lastname@example.org>
> On Tuesday 22 August 2006 02:59, Yoichi Yuasa wrote:
> Hi Yoichi,
> so far nobody commented on my recent mail, in which
> I explained why I
> think that the AU1X00 code in 8250.c is not entirely
> correct, so I assume
> nobody cares. I therefore modified my code to take
> the same approach,
> although I still have my doubts about it. Here's the
> updated patch:
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around