Re: Low Latency Patch

[Khimenko Victor]

In <[e-mail]> Robert Dinse ([e-mail]) wrote:
RD> On Sat, 1 Jul 2000, Khimenko Victor wrote:
>>
>> Ah. So you spotted problem yourself and STILL asking question below ??? Huh.
>>
>> >      Why can't this be made into a configuration option?
>>
>> Argh. Have you READ any Linus's letter on subject ? "It's all about
>> maintability, stupid". If you think tens (if not hundreds) ifdef's
>> spread all over kernel three is easier to maintain then external patch
>> then think again. Patch is not accepted NOT since goal is wrong. It's
>> completely other story: this patch makes maintaining of kernel sources
>> nightmare. Configuration option can not help maintainers. Not at all.

RD>      You know it should be possible to express disagreement without having
RD> to resort to name calling.

Linus tried it. You did not listen. Now we need to try other approach :-)

RD>      The low latency patch, which really significantly improves not only the
RD> usability of the kernel for real-time audio/video applications but also
RD> improves the general feel and functionality in a heavily loaded environment,
RD> and something that significantly affects security as the Solar Design patches
RD> do, are both things that significantly increase the functionality of the kernel
RD> relative to the degree that they detract from maintainability.

It's your opinion, not Linus's opinion. I'm REALLY glad Linus has more deep
understanding what's crap and what's not. Oh, I forgot: you just want benefits
of said patches, you will NOT maintain kernel. Yeah, of course in SUCH case
for YOU this patches are very appealing and non-intrusive: all problems
caused by hem will be Linus's problems not yours problems. BTW do not mix
Solar Designer patch and low latency patch. As Linus said quite a few times
some parts of Solar Designer patch like non-executable stack are just
"Wrong Things to do"(tm). Some other parts are integrated in kernel...

RD>      Certainly both of these things are of more widespread interest than say,
RD> packet radio hacks, and probably several dozen other features that are included
RD> in the kernel configuration.

Certainly both of these things affect MUCH more intimate parts of linux kernel
then packet radio hacks. And MUCH more dangerous (preemption point in wrong
place can easily freeze kernel due to deadlock and non-executable stack... it
was beaten to the dead already many times).

RD>      Personally, I would be thrilled if Linux were just stable on Sparc-32 SMP
RD> platforms but that's another issue.

And patches like mentioned above is way to make it LESS stable on you great
Sparc-32 SMP platform, not more stable.