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

[Christian Brauner <brauner@kernel.org>]

On Tue, Jun 30, 2026 at 04:22:25PM -0400, John Ericson wrote:
> I'm bumping this and adding new recipients again in light of the
> discussion happening elsewhere in
> <https://lore.kernel.org/all/a49ce818-f38d-41b0-bbf7-80b8aad998b1@app.fastmail.com/>.
> I don't want to count my chickens before they are hatched, but it is
> looking to me like a consensus in that thread is building around the
> ability to opt into intentionally empty/unusable root and working
> directories (at least with nullfs, maybe but less likely with other
> mechanisms instead).
> 
> That new functionality concretizes the motivation for what I am
> proposing in this thread: in such a world, there is little to no point
> binding listening sockets in the file system, because the containing
> directory would have to be conveyed by file descriptor anyways --- might
> as well just directly convey the socket to connect to by file
> descriptor. Likewise, abstract sockets are not appealing, because the
> abstract socket namespace is either too coarse-grained (leaking info in
> the same way root/cwd would), or too cumbersome to keep it from leaking.
> 
> To recap (with some slight changes, like renames), my latest proposal (a
> new version, not either of the two variations in the original email) is
> new syscalls `bind_unix_anon` and `connectat`, supporting a workflow
> like this:

Please stop sending a bunch of disparate patch series that all do
slightly related or overlapping things and point back at each other.

It's completely impossible to follow for anyone what's going on without
chasing down discussion state across multiple subsystems. The net people
have zero insight onto the fs struct discussions and it's completely
pointless to try and design all of this based on thin air. Nothing is
locked-in yet. This is not how this goes.

This frantic pushing of various features doesn't scale. It is requesting
costly review time for multiple RFC series.