- User Since
- Feb 4 2016, 4:45 PM (225 w, 5 d)
Tue, May 26
Mon, May 25
Question: You are introducting the flag RACK_HAS_SIN and you are setting it. But you are never reading it. Is that intended?
Thu, May 21
Tue, May 19
Mon, May 18
Sun, May 17
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.
Sat, May 16
Fri, May 15
This change is committed in r361080.
Thu, May 14
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?
Wed, May 13
Except for the whitespace issue, I'm fine with it.