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

On Fri, Jul 3, 2026, at 9:35 AM, Christian Brauner wrote:

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

I'm sorry for the confusion and the demands on your review time from
concurrently spreading my various Capsicum-like ideas across too many
threads. I can hereafter make things more single-threaded, as I'll
propose below. I hope that helps.

Just so we are all on the same page, at the moment I believe I have
created two RFC discussion threads, and submitted one RFC patch series:

- discussion thread: [RFC] Null Namespaces
  URL: https://lore.kernel.org/all/a49ce818-f38d-41b0-bbf7-80b8aad998b1@app.fastmail.com/ (local)
  Current status:
    - You (Christian) are writing nullfs/failfs FDs.
    - I am submitting nothing else (e.g. the actual null namespaces)
      until that is done.

- discussion thread: [RFC] connectat()/bindat() or an alternative design
  (this one)
  URL: https://lore.kernel.org/all/b1af80fc-a57c-408d-bdfe-fa6bae26eaca@app.fastmail.com/ (local)
  Current status: Working on one patch:
    - Patch Series: [RFC PATCH 0/3] coredump, net: fix layer violation
      with direct connection
      URL: https://lore.kernel.org/all/20260703073948.2541875-1-John.Ericson@Obsidian.Systems/ (local)
    - I am not submitting any UAPI changes until that is done.
  (Note: This thread had some code in the first message, but I never
  meant for that to be a formal submission, just a discussion aid, and
  the conversation moved on from that original design anyways.)

To make things maximally single-threaded, I could pause working on
"coredump, net: fix layer violation" (i.e. preparing a v2 based on what
you requested in your review) until you are done implementing
nullfs/failfs FDs. I am actually quite happy to do that if you want; I
should spend less time on the computer the next few days anyways, so the
timing is very good for that.

Either way, I can also henceforth not refer to yet-unwritten and
-unmerged patches like nullfs/failfs FDs in the motivation for other
things.

John

P.S. There is also my non-RFC bugfix series:

[PATCH net] af_unix: fix listen() succeeding on sockets in the wrong state
URL: https://lore.kernel.org/all/20260703081416.2583118-1-John.Ericson@Obsidian.Systems/ (local)

but I don't believe you were referring to that one, since I think
bugfixes are supposed to be submitted separately and immediately. Do
correct me if I am wrong.