In D25115#553203, @rscheff wrote:

Is EINVAL the correct return code? Or should this be EAGAIN / EBUSY?

OTOH, when a listening socket forks into a connected, it's too late to change on the newly connected socket - or can a socket transition back from CLOSED to LISTEN, after a session has concluded? (I know this is not typically done, and I haven't used such recycling of sockets myself either).

Question: You are introducting the flag RACK_HAS_SIN and you are setting it. But you are never reading it. Is that intended?

Hi Mike,
let me ask you two questions:

• If there is a wildcard socket bound against *:port, will this local port be used for a particular remote address?
• If these is a local port and address bound to a specific remote address port. Can you still bind a wildcard address to this port?

Thanks for the answers.
Best regards
Michael

This change is committed in r361080.

In D21669#546629, @cem wrote:

In D21669#476636, @tuexen wrote:

I'm contemplating what we gain by this change... We get a much more complex definition of mtod()

The complexity only comes with backwards compatibility for the 2-argument variant. With a flag day conversion to 1-arg, there isn't really any additional complexity.

OK. Then I would vote for a flag day.

and, for example, in the case of the SCTP source, which are shared with other BSD like platforms which don't make that change,

That seems like a self-inflicted SCTP problem. If SCTP is not native FreeBSD software, maybe it shouldn't live in the tree. If it is, it should not stand in the way of FreeBSD refactoring. It could use a trivial compatibility definition ifndef FreeBSD.

It is just a problem of supporting multiple platforms with the same code. But it can be handled by #ifdefs. And I agree, it should not stand in the way of generic code evolution.

we have to provide a way to do it still the old way. I guess, I have to replace mtod() by SCTP_MTOD() with the 2 argument semantic in the SCTP sources and then make platform specific definitions: On FreeBSD, call your version and do the explicit cast, on the other platforms just call mtod().

I don't think it's as complicated as that.

OK. Maybe I find an easier way.

Another point is that these mechanical global changes might make MFCing code harder...

Yes, that's true. That's what the complex definition is for. It helps, but does not remove merge conflicts.

So in my view, there is a price to pay. So I would like to understand what we gain.

If it doesn't make sense to you I don't think I can help you with that.

I'm not saying that it doesn't make sense. I just wanted to know what you think is the gain.

I think we should move away from these kinds of macros generally, and the gigantic functions we tend to have as well, but I don't see much enthusiasm in networking for that kind of thing. So I guess I'll butt out.

I think these are two points:

• macros involving type casts
• gigantic functions

I guess the first can be solved by small steps. The second is harder to not introduce regressions, but they are independent. Or am I missing something?

Except for the whitespace issue, I'm fine with it.