dumping options TCP_COMPAT_42

[Perry E. Metzger]

I'd like to yank the support for TCP_COMPAT_42 out of our tree -- I
doubt that there is any legitimate user of the option any
longer. 4.2BSD was more than 20 years ago at this point.

Absent any groundswell of supporters for TCP_COMPAT_42 I'll be
removing it from the tree in a couple of days.

[der Mouse]

Post by Perry E. Metzger
I'd like to yank the support for TCP_COMPAT_42 out of our tree --

Sic transit gloria NetBSD.

One of NetBSD's strengths, to me, has always been its *extreme* degree
of compatability. I've even seen it trumpeted somewhere - on the
website, probably.

I'm sorry to see it losing that. (Yes, I realize that these removals
are not a done deal yet. That they are even being seriously
contemplated means that there has been a major sea change in the
attitude towards compatability; the stance I saw as such a strength has
already been lost, or the idea probably wouldn't even have been
floated, and certainly wouldn't've survived the first few responses.)

I also think that a KLOC comparison is pretty totally bogus, since we
have so many dozens more ports, each of which contributes a biggish
chunk of code. Try comparing the kernels without any of the MD code,
I'd say, to get a more informative number.

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Havard Eidnes]

Post by Perry E. Metzger
I'd like to yank the support for TCP_COMPAT_42 out of our tree -- I
doubt that there is any legitimate user of the option any
longer. 4.2BSD was more than 20 years ago at this point.
Absent any groundswell of supporters for TCP_COMPAT_42 I'll be
removing it from the tree in a couple of days.

The above isn't exactly a technical argument why retaining the
compatibility in our code is a bad thing, and the argument as
stated seems to be more about the name of the option than
anything else.

Reading the code, it doesn't appear that this is an option which
is causing any significant bloat, or any of that code being on a
performance-critical code path. From options(4):

options TCP_COMPAT_42
TCP bug compatibility with 4.2BSD. In 4.2BSD, TCP sequence numbers were
32-bit signed values. Modern implementations of TCP use unsigned values.
This option clamps the initial sequence number to start in the range 2^31
rather than the full unsigned range of 2^32. Also, under 4.2BSD,
keepalive packets must contain at least one byte or else the remote end
would not respond.

So, what, exactly, are the technical reasons you want to remove
the option and the associated few lines of code?

Regards,

- Håvard

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hauke Fath]

Post by Havard Eidnes
So, what, exactly, are the technical reasons you want to remove
the option and the associated few lines of code?

Seconded.

Others may know more, but ISTR that the option is relevant for on-the-wire
interoperability with 4.2BSD derived legacy OSes. That's something we may
still want.

hauke


(What is the English equivalent for "Putzzwang"? ;)


--
"It's never straight up and down" (DEVO)



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Hawkinson]

If there are no longer any conceivable users of the code, there is no
reason to maintain it.

I don't understand why this is the question.

Why is it apparent that the maintenance cost is higher
than the removal cost, esp. in terms of unintended consequences?

(It is clear that there are "conceivable users" of the code;
is that good enough, or are you actually suggesting a higher
standard?)

--jhawk

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Perry E. Metzger]

Post by Havard Eidnes

Post by Perry E. Metzger
I'd like to yank the support for TCP_COMPAT_42 out of our tree -- I
doubt that there is any legitimate user of the option any
longer. 4.2BSD was more than 20 years ago at this point.
Absent any groundswell of supporters for TCP_COMPAT_42 I'll be
removing it from the tree in a couple of days.

The above isn't exactly a technical argument why retaining the
compatibility in our code is a bad thing, and the argument as
stated seems to be more about the name of the option than
anything else.

If there are no longer any conceivable users of the code, there is no
reason to maintain it.

Perry

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Perry E. Metzger]

Post by Hauke Fath

Post by Havard Eidnes
So, what, exactly, are the technical reasons you want to remove
the option and the associated few lines of code?

Seconded.
Others may know more, but ISTR that the option is relevant for on-the-wire
interoperability with 4.2BSD derived legacy OSes.

No, it really isn't. Everyone fixed these bugs decades ago -- and I
mean *decades*. There are fully grown adults who were born after these
bugs were fixed. You are going to be very very hard pressed to find a
host that still has them.

You seem to believe there are pure 4.2 stacks still out there, but
there aren't. If you had such a stack, it couldn't communicate over
the internet. Hell, it wouldn't even have congestion avoidance. No has
had such a stack in production code for a very, very long time.

If a machine had said bugs, it would be impossible for any modern
machine to speak to it anyway. First, no one using NetBSD actually
turns on the option. Second, no similar support is present in MacOS,
Windows or any other modern Unix. There wouldn't be any boxes for the
machine to speak to.

If someone can stand up and say "I have had a reason to turn this flag
on in the last ten years", I'd be rather astonished.

Perry

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[William Allen Simpson]

Post by Perry E. Metzger
No, it really isn't. Everyone fixed these bugs decades ago -- and I
mean *decades*. There are fully grown adults who were born after these
bugs were fixed. You are going to be very very hard pressed to find a
host that still has them.
You seem to believe there are pure 4.2 stacks still out there, but
there aren't. If you had such a stack, it couldn't communicate over
the internet. Hell, it wouldn't even have congestion avoidance. No has
had such a stack in production code for a very, very long time.
If a machine had said bugs, it would be impossible for any modern
machine to speak to it anyway. First, no one using NetBSD actually
turns on the option. Second, no similar support is present in MacOS,
Windows or any other modern Unix. There wouldn't be any boxes for the
machine to speak to.
If someone can stand up and say "I have had a reason to turn this flag
on in the last ten years", I'd be rather astonished.

With all due respect to jhawk and others, I think that Perry is correct,
even though Perry is doing a bit of proof by assertion....

15 years ago, we usually had to hack in 4.2 compatibility, because there
were old machines still lying around. They already couldn't communicate
with many systems on the Internet, but sometimes were needed over local
links (in 1991, I donated a 486 to the local Arbornet community BBS to
serve as a front end).

10 years ago, I'm reasonably sure that every such system I've ever known
was long retired. Even poor community and school systems are retired
that cannot get spare parts.... Nothing lasts forever.

In general, I'm in favor of retiring buggy systems and deprecating bad
practices with prejudice.

OTOH, perhaps NetBSD would be useful in a museum to communicate with
ancient systems as a demonstration? Is that a target audience?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

Post by Hauke Fath
Others may know more, but ISTR that the option is relevant for
on-the-wire interoperability with 4.2BSD derived legacy OSes.

No, it really isn't. Everyone fixed these bugs decades ago -- and I
mean *decades*.

And, of course, we all know that everyone promptly switched over to the
fixed versions.

You seem to believe there are pure 4.2 stacks still out there, but
there aren't.

I don't believe you have the evidence to back that up. I don't believe
anyone can. There simply is no way to know what is still running in
legacy applications. There are PDP-11s still out there; heck, I think
there are still PDP-8s out there. I'd be astonished if there weren't
4.2 stacks still in live use.

If you had such a stack, it couldn't communicate over the internet.

Not communicating with the Internet at large, no. So? Are you under
the delusion that that is the only networking going on? Surely you
know better than that.

If a machine had said bugs, it would be impossible for any modern
machine to speak to it anyway.

All the more reason to have the compatability option, so that we can
distinguish ourselves from the pack by being able to speak with it!

If you don't want backward compatbaility, you know where to not find
it.

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by der Mouse

Post by Perry E. Metzger
You seem to believe there are pure 4.2 stacks still out there, but
there aren't.

I don't believe you have the evidence to back that up. I don't believe
anyone can. There simply is no way to know what is still running in
legacy applications. There are PDP-11s still out there; heck, I think
there are still PDP-8s out there. I'd be astonished if there weren't
4.2 stacks still in live use.

I think it's quite possible. Especially if these have a special communication
board that can not be used in newer systems.
It's not uncommon to see very expensive equipements (e.g. in physic or chemic
labs) connected to a computer via a custom communication board, for
which a PCI version doesn't exists (and you wouldn't have the driver
anyway).

[William Allen Simpson]

Post by Manuel Bouyer

Post by der Mouse

Post by Perry E. Metzger
You seem to believe there are pure 4.2 stacks still out there, but
there aren't.

I don't believe you have the evidence to back that up. I don't believe
anyone can. There simply is no way to know what is still running in
legacy applications. There are PDP-11s still out there; heck, I think
there are still PDP-8s out there. I'd be astonished if there weren't
4.2 stacks still in live use.

I think it's quite possible. Especially if these have a special communication
board that can not be used in newer systems.
It's not uncommon to see very expensive equipements (e.g. in physic or chemic
labs) connected to a computer via a custom communication board, for
which a PCI version doesn't exists (and you wouldn't have the driver
anyway).

It seems to me that now others are using proof by assertion.

My understanding of the goals of this project are to run it on as many
platforms as possible. So, the answer to the above possible issues are
to port NetBSD to PDP-8 and PDP-11.

If the goal is to support museum exhibits running their original OS, then
why don't we have COMPAT for every other variant (or buggy) implementation,
such as XINU, Ultrix, various insecure (Kent) flavors of IPsec?

There were millions of those IPsec boxen sold, as opposed to mere hundreds
or thousands of PDP- or Perkin-Elmer (my first port) or what-have-you....

I don't run 386bsd on my old 60 MHz Pentium anymore, either!

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by William Allen Simpson

Post by Manuel Bouyer

Post by der Mouse

Post by Perry E. Metzger
You seem to believe there are pure 4.2 stacks still out there, but
there aren't.

I don't believe you have the evidence to back that up. I don't believe
anyone can. There simply is no way to know what is still running in
legacy applications. There are PDP-11s still out there; heck, I think
there are still PDP-8s out there. I'd be astonished if there weren't
4.2 stacks still in live use.

I think it's quite possible. Especially if these have a special communication
board that can not be used in newer systems.
It's not uncommon to see very expensive equipements (e.g. in physic or chemic
labs) connected to a computer via a custom communication board, for
which a PCI version doesn't exists (and you wouldn't have the driver
anyway).

It seems to me that now others are using proof by assertion.

Actually I know peoples which have been in such situation (altough I don't
know if these boxes were running a brocken TCP stack). We periodically
get requests on the internal admin list for hardware parts for 15 to 20
year old systems, driving some lab equipement that can't be (easily)
remplaced.

Fortunably these old systems have eletronics that are not too hard
to repair for someone knowlegeable.

Post by William Allen Simpson
My understanding of the goals of this project are to run it on as many
platforms as possible. So, the answer to the above possible issues are
to port NetBSD to PDP-8 and PDP-11.

And write a driver for the proprietary, undocumented communication board,
and then make a compat_foo to run the software ?

Post by William Allen Simpson
If the goal is to support museum exhibits running their original OS, then

In my case it's not museum. It's used for day job by peoples that don't care
about computers. They just need to be able to use their equipement.

Post by William Allen Simpson
There were millions of those IPsec boxen sold, as opposed to mere hundreds
or thousands of PDP- or Perkin-Elmer (my first port) or what-have-you....
I don't run 386bsd on my old 60 MHz Pentium anymore, either!

But I suspect you're not a chemist that has a spectrometer connected
to your 60 MHz Pentium.

[Rui Paulo]

Post by Perry E. Metzger
I'd like to yank the support for TCP_COMPAT_42 out of our tree -- I
doubt that there is any legitimate user of the option any
longer. 4.2BSD was more than 20 years ago at this point.
Absent any groundswell of supporters for TCP_COMPAT_42 I'll be
removing it from the tree in a couple of days.

On a side note, I'm going to remove COMPAT_42 (note, not
TCP_COMPAT_42) code if no one objects. It's not on our kernel config
files, it's not on options(4).

I've checked 386BSD source and they don't even add COMPAT_42 to the
GENERICISA config file, so this is dead code for more than a decade.

--
Rui Paulo



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Perry E. Metzger]

Post by der Mouse

Post by Perry E. Metzger
You seem to believe there are pure 4.2 stacks still out there, but
there aren't.

I don't believe you have the evidence to back that up. I don't believe
anyone can.

I'll put this another way:

I think it would be very hard to find someone who can claim that
they've actually needed to turn on TCP_COMPAT_42 since NetBSD
started. I don't count turning on the option out of curiosity or for
debugging -- I mean someone who needed to turn it on out of a need to
communicate with box running a 4.2 stack.

Note that's not just "I don't think anyone claims to use it now",
that's "I don't think anyone has used it EVER". The option was in
serious use in the pre-NetBSD era because some prerelease 4.4BSD and
4.2BSD machines co-existed, but I would not be surprised to discover
it has never been turned on for real under *NetBSD* in the entire
existence of our project.

If someone comes forward and says "no, I've used it and I'm still
using it" I think it is fine to leave the option in place. Among other
things, that person could attest to the fact that the code still
works. However, as it stands, beyond code inspection, how do we even
know the code hasn't rotted? It is entirely possible that it has
*never* been tested in real use. Sure, it "looks" okay, but do we
really know it is bug compatible with real 4.2 stacks when no one has
seen an unpatched 4.2 stack in this long?

It is possible that I'm wrong and someone out there is using the thing
regularly, but I strongly suspect otherwise. I posted in order to find
out if anyone would come out of the woodwork. So far, what we've
gotten is a couple of people protesting that someone might use it, but
no one has actually claimed that they themselves have used it let
alone that they still use it.

Post by der Mouse
If you don't want backward compatbaility, you know where to not find
it.

I like backwards compatibility. I don't think there is anything in
this case for us to still be backwards compatible *with*. Sure, we can
speculate that out there somewhere there's a guy who uses an old
Pyramid he found in a dumpster in 1989 for running the sump pump in
his basement and desperately depends on a NetBSD machine to
communicate with it, but it seems a trifle unlikely. If that person
exists, well, we can keep the code for their benefit.

One amusing side note: I looked recently at the Open Solaris
sources. They still have a #define for TCP_COMPAT_42 but they have no
code that is conditionalized on it. This is what happens when you
leave stuff to rot for decades.

[Blair Sadewitz]

http://lists.freebsd.org/pipermail/freebsd-net/2006-February/009886.html

You can apply for an account @ 386bsd.org; it may be for this machine.
I applied.
Anyone else want to try this out?
--
Support WFMU-FM: free-form radio for the masses!

<http://www.wfmu.org/>
91.1 FM Jersey City, NJ
90.1 FM Mt. Hope, NY

"The Reggae Schoolroom":
<http://www.wfmu.org/playlists/RS/>

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Anders Magnusson]

Post by Perry E. Metzger
I think it would be very hard to find someone who can claim that
they've actually needed to turn on TCP_COMPAT_42 since NetBSD
started. I don't count turning on the option out of curiosity or for
debugging -- I mean someone who needed to turn it on out of a need to
communicate with box running a 4.2 stack.

I actually had to turn it on a year ago to be able to do a backup from a
really
old machine I have running, the problem revealed itself when large
amounts of
data were transferred, TCP_COMPAT_42 solved the problem.

I don't know if it's a common situation though, but it was nice to be
able to
get it working :-)

(There are actually some machines that uses XNS also :-)

-- Ragge

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Perry E. Metzger]

Post by Anders Magnusson
I actually had to turn it on a year ago to be able to do a backup
from a really old machine I have running, the problem revealed
itself when large amounts of data were transferred, TCP_COMPAT_42
solved the problem.
I don't know if it's a common situation though, but it was nice to
be able to get it working :-)

Okay, that's a good enough reason to leave the thing.

Perry

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Perry E. Metzger]

Post by Perry E. Metzger

Post by Anders Magnusson
I actually had to turn it on a year ago to be able to do a backup
from a really old machine I have running, the problem revealed
itself when large amounts of data were transferred, TCP_COMPAT_42
solved the problem.
I don't know if it's a common situation though, but it was nice to
be able to get it working :-)

Okay, that's a good enough reason to leave the thing.

BTW, since this need is pretty rare, would you object to having the
option removed from GENERIC but the infrastructure left in place? It
would reduce clutter a bit. The #define isn't really needed given that
there is a sysctl.

Perry

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Tue, 14 Nov 2006 09:32:32 -0500, "Perry E. Metzger"

Post by Perry E. Metzger

Post by Perry E. Metzger

Post by Anders Magnusson
I actually had to turn it on a year ago to be able to do a backup
from a really old machine I have running, the problem revealed
itself when large amounts of data were transferred, TCP_COMPAT_42
solved the problem.
I don't know if it's a common situation though, but it was nice to
be able to get it working :-)

Okay, that's a good enough reason to leave the thing.

BTW, since this need is pretty rare, would you object to having the
option removed from GENERIC but the infrastructure left in place? It
would reduce clutter a bit. The #define isn't really needed given that
there is a sysctl.

I have a very strong preference for sysctls over #ifdef -- please do make
that change.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Tom Spindler]

Post by Steven M. Bellovin

Post by Perry E. Metzger

Post by Perry E. Metzger
Okay, that's a good enough reason to leave the thing.

BTW, since this need is pretty rare, would you object to having the
option removed from GENERIC but the infrastructure left in place? It
would reduce clutter a bit. The #define isn't really needed given that
there is a sysctl.

I have a very strong preference for sysctls over #ifdef -- please do make
that change.

<metoo />


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Rui Paulo]

Post by Perry E. Metzger
BTW, since this need is pretty rare, would you object to having the
option removed from GENERIC but the infrastructure left in place? It
would reduce clutter a bit. The #define isn't really needed given that
there is a sysctl.

The issue in the first place, I think, was that the compiler can
optimize the code path if we have the define.
That said, I don't know how much does that actually buy us.

--
Rui Paulo



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Perry E. Metzger]

Post by Rui Paulo

Post by Perry E. Metzger
BTW, since this need is pretty rare, would you object to having the
option removed from GENERIC but the infrastructure left in place? It
would reduce clutter a bit. The #define isn't really needed given that
there is a sysctl.

The issue in the first place, I think, was that the compiler can
optimize the code path if we have the define.
That said, I don't know how much does that actually buy us.

The option in the kernel config only sets the default value of the
sysctl variable -- it does not impact the code per se.

Perry

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Rui Paulo]

Post by Perry E. Metzger

Post by Rui Paulo

Post by Perry E. Metzger
BTW, since this need is pretty rare, would you object to having the
option removed from GENERIC but the infrastructure left in place? It
would reduce clutter a bit. The #define isn't really needed given that
there is a sysctl.

The issue in the first place, I think, was that the compiler can
optimize the code path if we have the define.
That said, I don't know how much does that actually buy us.

The option in the kernel config only sets the default value of the
sysctl variable -- it does not impact the code per se.

Oh, you're right. My mistake.

--
Rui Paulo



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de