[RFC] connectat()/bindat() or an alternative design

Hello, I am interested in seeing something like the BSD's connectat/bindat in
Linux.

The deficiencies with traditional `bind`/`connect` for unix sockets are
well-known. The advantages of openat2 over openat over open are also well-known, so I
won't waste anyone's time restating either.

https://lore.kernel.org/netdev/4FCF171B.8000207@parallels.com/ (local)
https://lore.kernel.org/all/CAEnbY+co6YLXANfeMnfBOBs8Ba_Sbdqz0Ahm8RzAhRF7MrxL4Q@mail.gmail.com/ (local)

Here are two previous times this was raised, unfortunately with no replies.
Hoping this third time is the charm!

To hopefully give the discussion a bit more concreteness, I have taken a stab at
two refactors (with an LLM, full disclosure) to get a sense of what the
approaches look like. (To be clear, these are not patches I am trying to
formally submit, these are just sketches to guide the conversation. I haven't
built or tested them, just read them.)

https://github.com/Ericson2314/linux/tree/bindat-connectat

1. 9b72f7e2add657cfd0d755c7ea24e56f1aab7025

The first is a straightforward port of connectat/bindat, except for a (not yet
used) flags argument so the likes of `AT_SYMLINK_NOFOLLOW` and `AT_EMPTY_PATH`
could someday be supported. (Or `RESOLVE_NO_SYMLINKS` from `openat2` for
something more stringent than `AT_SYMLINK_NOFOLLOW`.)

I made some effort to deduplicate things as much as possible, and support
io_uring. So the (again WIP) diff is somewhat elegant. Still though, to me at
least, a glaring issue with this design is that we are making new syscall and
other "entrypoint" machinery for *all* socket types, when only unix sockets
stand to benefit from this. For everything else, the other parameters are just
nonsense to be ignored or, worse, confused by.

That brings me to the next attempt, which I personally prefer:

https://github.com/Ericson2314/linux/tree/sockaddr_un2

1. 96c45c5cc43799f95a1a90a87cfaccf9377b82da
2. d183785e63d0b224de21fc4f7e505eef99b27592

Here, instead of making a new `connect`/`bind`, I've made a new `struct
sockaddr_un` alternative.

Actually, there are two commits. The first commit cleans up an internal data
structure to decouple it from `struct sockaddr_un` and thus the stable syscall
ABI. I like this commit in any event, but it is fine to also just view it as
prep for the second commit.

In that second commit, a new `struct sockaddr_un2` is created, which has a
pointer to a path rather than an inline path to get around path length issues,
an fd / `AT_FDCWD` for at-relative argument, and the flags argument.

I very much like how this localizes what is useful for unix sockets to just that
case, without bloating the code for the other socket types. Even including the
preparatory first commit, this way is still fewer lines of code, too. It feels
like the correct approach to me.

Ultimately though, I am happy to go with whichever approach the networking
maintainers go with --- either would be preferable to the status quo. If one of
those (or something else!) looks promising, let me know, and I am happy to take
the time to polish it up into a proper submitted patch.

Thanks,

John