Jonathan T. Looney jtl at
Sat Jan 9 15:44:37 UTC 2016

On 1/8/16, 4:45 PM, "owner-freebsd-transport at on behalf of Sam
Kumar" <owner-freebsd-transport at on behalf of
samkumar99 at> wrote:

>I am working with the code for the TCP Stack.

Thanks for choosing FreeBSD! :-)

>In summary I suspect that the TCPS_HAVERCVDFIN macro needs to be
>but I'm not sure whether that is actually the case. I wanted to open a
>discussion about this to explore whether this is a legitimate issue.

In short, it appears you are correct that the macro name does not match
the reality of what it checks. This is likely to cause a problem at some
point, so it is legitimate to suggest it be fixed.

However, this is non-trivial for at least several reasons:

A) Changing this will require thoroughly testing all the impacted code.
That requires both a thorough conformance-testing suite, as well as
thorough performance tests (in case the change impacts performance).
However, I don't think the FreeBSD project itself has such things at the
moment. (gnn@ might have more to say on this topic. :-) )

B) Even if the code you reference made an erroneous assumption, others may
have written other code that assumes the current behavior. Changing the
current behavior to be "more correct" might impact other code in subtle
ways. (Hence, the need for testing: see (A).)

C) Even if we can fully qualify that *our* code works correctly after
changing this, third parties may have extended our system in ways that
rely on the current behavior. (Hence the need for testing. They "own" that
to some extent. But, we owe them some duty to be careful about changing
basic building blocks they may use.)

D) Changing this may make it harder to port code from other OSs. For
example, OpenBSD uses the same definition of TCPS_HAVERCVDFIN that we do.
On the other hand, it looks like NetBSD updated theirs (17 years ago!) to
something closer to what you suggest. So, porting code from other OSs may
already be problematic.

Because we now have some level of TCP stack modularity, we *should* be
able to build a TCP module that does what you suggest and let people try
it out while maintaining the option to fallback to the main stack if
things go haywire. However, that is more complicated than I wish it were
because it currently requires *copying* code rather than just compiling
the same code a second time. I have a proposal to address that, but need
to circulate it and get feedback.

In the meantime, we can talk through some of these obstacles and see how
we want to handle this. We can always define two macros (the old and new
one) and change the macro usage from the old to the new one as we feel
comfortable. If there is desire to proceed, I would recommend that as the
way forward, assuming we can satisfy the testing concerns.


More information about the freebsd-transport mailing list