> 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.
Granted. I don't feel strongly one way or the other. I agree with
previous comments that Linux shouldn't have to fix problems with other
systems, but I'm also pragmatic.
I haven't explored the kernel tcp code, so I didn't know how the
workarounds were implemented. I was thinking that they might be clearly
separated and commented exceptions for broken implementations that could
be ifdef'd without a great deal of effort. Apparently not.
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.
Might I note that the PC/TCP client workaround should not be in the
kernel configuration using your argument? Apparently, workarounds are
made configurable on a case-by-case basis. I expect the workarounds
themselves can create problems for well-behaved systems.
All of the above MHO from an end user - not kernel developer - viewpoint.
Thanks for the feedback (and the next gen filesystem development!).
Geof Goodrum
Voice: +1-301-457-5100
Email: Geoffrey.P.Goodrum@noaa.gov
-
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/