> On Fri, 16 Apr 1999, Stephen C. Tweedie wrote:
>
> > Can you _imagine_ the pain of maintaining multiple different
> > incompatible sets of tcp behaviour in the kernel? It's a crazy idea.
> ...
> > The world has an internet now. It really doesn't make much sense to
> > compile kernels which have problems talking to certain types of machine,
> > since as soon as you are on the net it's only a matter of time before
> > you meet one of them.
>
>
> If you had an Intranet without any misbehaving systems and no Internet
> connection (!) or an isolated Beowulf cluster, leaving the workarounds out
> would seem to be another appealing feature of a custom kernel. Not that I
> would expect a significant performance difference, but "significant" is
> relative.
>
This is my main contention. If i dont need them i shouldnt have them.
The relative perfomance differences might actually become important when
making performance comparisons with other OSes which dont have these
'fixes' or on low end systems.
Ugly as #ifdefs may look, they make the code more maintainable in the
sense that you know why some code is in there. I am sure in a short time
that the sun or apple fix will look as if it belongs there in the first
place.
And sure you have to interwork with broken systems, but baby-sitting
vendors(which is what is happening in this case) should be discouraged.
Maybe a time limited patch is a good concept.
>
> Might I note that the PC/TCP client workaround should not be in the
> kernel configuration using your argument?
No it shouldnt.
Something along BSDs "HACKS" config option is probably a good idea.
I can volunteer to scan the TCP code, if this is deemed acceptable -- it
would be extremely difficult to find code that is already assimilated
and not commented.
cheers,
jamal
-
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/