Hi Willy,
Since you mentioned this topic in the 3.1-dev2 release notes, let's
start the discussion again I suppose.
To summarize what I was saying at the end last time:
1. Duplicating abns into abns2 introduces a non-trivial amount of cruft
and awkward bits and pieces
2. I still don't see the abns/abns2 split as worth it, as opposed to a
`pad { on | off }` (or similar) bind argument being added to the abns spec
Tristan
On 09/03/2024 14:02, Tristan wrote:
On 09/03/2024 18:09, Tristan wrote:
Hi Willy,
On 09/03/2024 16:51, Willy Tarreau wrote:
Hi Tristan,
On Sat, Mar 09, 2024 at 04:20:21PM +0000, Tristan wrote:
To be honest, I don't think this is unfixable. It's just a matter of
how
much code change we think is acceptable for it.
I don't mind about the amount of changes. "we've always done it like
this"
is never a valid excuse to keep code as it is, especially when it's
wrong
and causes difficulties to add new features. Of course I prefer invasive
changes early in the dev cycle than late but we're still OK and I don't
expect that many changes for this anyway.
Agreed on not shying away from amount of changes.
I tried to follow that route, being generous in what I was willing to
touch, but ran into the issue of protocols and socket families being a
1:1 binding.
So adding a new socket family *requires* adding a new protocol too,
which isn't too hard but spirals a bit out of control:
- protocol_by_family is a misnomer, and it is actually protocols *by
socket domain* (which is still AF_UNIX, even with family
AF_CUST_ABNS2, and ends up overriding standard socket/abns protocol)
- but you can't just change that, because then other things stop
working as some places rely on socket domain != socket family
Actually, following up on this, I'm more and more convinced that it
actually makes things somewhat worse to take this approach...
At least I don't see a good way to make it work without looking very
bad, because in a few places we lookup a protocol based on a
socket_storage reference, so we have truly only the socket domain to
work with if no connection is established yet.
While it sounds like shying away from deeper changes, it seems to me
that a bind/server option is truly the right way to go here.
Tristan
