In <Pine.LNX.4.10.10007231514200.8103-100000@dax.joh.cam.ac.uk> James Sutherland (jas88@cam.ac.uk) wrote:
JS> It's a risk, yes. The current situation is complete shit, the proposed
JS> stop-gap is pretty crap. Since you admit any more major improvement is
JS> impossible, we should stick with "pretty crap" for the time being.
We SHOULD ??? You ARE joking, right ? Last time I checked Linus had power
to make such decisions, not you. And he stated his approach quite clearly:
-- cut --
Finally, even if the above isn't true, I often reject bug-fixes.
Bug-fixes are _often_ worse than the bug they fix, even with serious bugs.
Because a lot of bug-fixes are "band-aid" - not fixing the bug properly.
And band-aid is BAD. It's worse than even a crashing machine. Because
band-aid never goes away, and nobody cleans it up.
I prefer to have a known bug that will eventually get fixed than an ugly
solution that will hide it forever.
Linus
-- cut --
You do not want to play by this rules ? Fine - go to FreeBSD, BeOS or Windows.
Full removal of this crap (so you will be unable to use hdparm to play with
UDMA settings anymore) cas pass Linus test, Andre's patch - no.
JS> Andre's patch is far too big for what it is supposed to do. However, the
JS> fundamental idea (block the API calls which shouldn't exist in the first
JS> place) is fine.
It's NOT. It's band-aid, not proper solution.
>> > Because SOME of the power IS needed, some of the time, ATM. Take away as
>> > much of it as possible now, then replace the remainder with conventional
>> > weapons and remove the rest.
>>
>> The same history all the time: first part can be done. But if you'll do this
>> you'll lost [almost] all hope to do second.
JS> The second part may not even be needed. One if statement is hardly the end
JS> of the kernel.
May be. If so then Linux is doomed and you can play other games. But it's
general Linus principle and you need REAL STRONG argument to go against
this principle. PLEASE try to undertstood that you DO NOT need al lot of
arguments to reject such patches - Linus's rule cuted above is more then
enough. Quite an opposite: you need REAL STRONG argument to apply such patch.
>> > You do NOT need a "do arbitrary crap" interface to upgrade firmware. You
>> > need an "upgrade firmware" interface.
>>
>> See above. In indeal world - yes. In real world - no.
JS> Remove the "do arbitrary crap" API - it should never have existed. If some
JS> other feature is needed, it will be added - that's another issue.
Hmm. I think that such patch Linus can accept. I'm not sure Andre will be
very happy with such patch though: this will remove possibility to play with
UDMA modes and Andre looks quite fond of Linux UDMA support.
>> > If the kernel is providing an adequate API, we no longer need ANY aspect
>> > of the "raw crap" interface. In the mean time, we need SOME aspects - but
>> > should block the rest.
>>
>> See above. If you'll do this now you will NEVER got to the point where you
>> do not need "raw crap" interface.
JS> Remove the raw crap interface first. If someone needs a feature it used to
JS> provide, implement that properly at a later date.
It'll remove ability to play with UDMA settings and such. So you brand-new
system will use what was selected by defaul - DMA33 or may be even PIO mode
instead of UDMA66/UDMA100 and you will have no knobs to change it. Arrange it
with Andre first, Ok ?
-
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/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:20 EST