From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-b7-smtp.messagingengine.com (fout-b7-smtp.messagingengine.com [202.12.124.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3558527AC57; Thu, 2 Jul 2026 03:23:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.150 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782962588; cv=none; b=D+nrEORy6FY85mccG6/5Hn6yRk7vrik/fs3AZ7EQEJXEjoY2yoNrNn5SJlalDA+HrRQrI1u+EZvoH7WLflbuDNAypQmjaklEPhJAVQK2E4sWTHiUQupmxkSj2W1qDFBWXb4qkOB1YYbskybYqQ+1KagBmUubvpv2xeZl3kFG11Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782962588; c=relaxed/simple; bh=h52IPXEO3GErwPUXSaSWfDdjb5VBspL/PzrUT7vQqEg=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=BvgR7UeZyF40zT1yuvIDL3bwveaPG8E2WVygpD75sym2HUIraPc4zyrU+NSZ7CxhagTCIIrAqyhwz6z1aJHYGYC0bYrSlodGNwbwybYWSbzyO0bWgaA5dOd2bEeeCqnrVSPxOfNibUdoul2NG0vXhopT086E8aEps5TXfaSvlfs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=johnericson.me; spf=pass smtp.mailfrom=johnericson.me; dkim=pass (2048-bit key) header.d=johnericson.me header.i=@johnericson.me header.b=dR8H/USd; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=CjDFCovs; arc=none smtp.client-ip=202.12.124.150 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=johnericson.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=johnericson.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=johnericson.me header.i=@johnericson.me header.b="dR8H/USd"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="CjDFCovs" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfout.stl.internal (Postfix) with ESMTP id 3CFB21D0006E; Wed, 1 Jul 2026 23:23:05 -0400 (EDT) Received: from phl-imap-16 ([10.202.2.88]) by phl-compute-05.internal (MEProxy); Wed, 01 Jul 2026 23:23:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=johnericson.me; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm3; t=1782962585; x=1783048985; bh=+ofwFd0BgfH978UubVq3+U13sv3WhECD ex7It7QGGUQ=; b=dR8H/USdaOxwA8CPdfFY89sM3BC1+DOOrvJsPM3+yZLXRQqq 40bkEMX6zts4qFPZfegYrUkvWhny8WZOou0hVp8MMv3wwzuu8w53mhLxO9QqqKYm WUYWV1aK9oMsrzetc6Re2IhRdt9PCZKdwsIoSzfl3sICf588keEwpKde8Akd+h1M FbJo+msUq4rwBt5q7Warf1SRTIKq9emrZHPNtLAkF3gnAz8rBNraUWigiyYBjUsC 6XnLUhRB/w3HAQ+WzAxvWcn+odFNqMpo0Rir8XMIXHORYlSCSRq+nn2pgJ/13EQ6 DStp+B1p1Cnf6m4wZ4Ge2h2cTsjtFODwsn/BrA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1782962585; x= 1783048985; bh=+ofwFd0BgfH978UubVq3+U13sv3WhECDex7It7QGGUQ=; b=C jDFCovsnejQgJrhSNtYSSOvrC4hJ47Dd1Gav+2htmIldr4Co+5euDii0MPGSM7O8 pWhQ11olagALAMydFq/u+YlUeG/5xYOlf8W6wFr4GlfVWVhH1/dgfSvecfi9LiK9 vi3g8jaVeNSdoUY4prtQFVLHYALNkZquk4nVOajVdkkz50qf5ux7ndwf6CzP7p7N l/5wiKWc1rkeCnYpr90UPOnLpbAGAF4gXHJMgBAOE/mFepUCEPxMVGaAJIa3CD9A HqlUkznOcwB4dPgd4qwT4nWs5pglSLA/HXgCyIIVX5mlhxHCsDfWDhlU7qUU0FJH XTGDRfJIjprBlckCmwlqw== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTFM4tHx1Q26ZIh3UHc0hey+73JTKicWAXjZ52Lldta0RJQwSyaD00TgDAIOLdvcqT ZtskFQh1q65fyyZhjZuDmkQcsycDoBQkNBcRSf9ESab22aSbz5H4ecg2npHMwRQQ3bvvPK 6h7ypaUo586eXVYjVCnGPD4Y3xrUo+EYT+l0TOEqhIoXIHuVmPkmWlteO8t1Cr+Ae6YZJh ZXwuwaQzAqI2+ebnMhG0DrmGevo7feD4kb6Rv8skIvSe8sLe+VpUezCTgtTpp/KcKEH8pT 18aJSibAKd95jY6Dqc3PoFuJijcVZUxKcEEj6FETnqYBZbdZ7V9eYFLrh7QkgAE5CzQ7ZL wKATY6bxfLhaqtAXkUyRZ2JQ7lOh+BhbEsfnCQjIUIp2Yb0Ig+9+ktLi6kL+gestfZKKFk WSlmAqJuhhDtJ15qdQzwo0rGS12l5GRwPCt+lzh1ibZZJXP8ayRL0iStOoXTlTGD/3UqgG a8F593FosQmmIgLoVoqikr/BxYXa9B2v94FvnrKYgv2Fh90yNHdii44R0eDLAeDolyKG89 ZkwFpSaa3bRWAId0PEUMoEDEHfmtFY+ibABbIeBjkcTHd767DTt1LXPP3K41/JVHZ+Yxgy baldltiKOkr2fS92PstYI/tB/OaepR/ZkVIuBmME1GHkjEl3SZlxzT2Le3NA X-ME-Proxy: Feedback-ID: ieb4144f1:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 5F9CE2CC0083; Wed, 1 Jul 2026 23:23:04 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: Aqzxz9K-cSE- Date: Wed, 01 Jul 2026 23:22:43 -0400 From: "John Ericson" To: "Cong Wang" Cc: "Li Chen" , "Andy Lutomirski" , "Christian Brauner" , "Jens Axboe" , "network dev" , linux-fsdevel , "Sergei Zimmerman" Message-Id: In-Reply-To: References: <455281ec-3ee1-4f27-989b-c239f0690d8b@app.fastmail.com> <66eb8227-85b6-4684-a4fa-e3e17ac2fa45@app.fastmail.com> Subject: Re: [RFC] connectat()/bindat() or an alternative design Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, Jul 1, 2026, at 8:32 PM, Cong Wang wrote: > Hm? Why not just setsockopt()? Something like: > > struct unix_lookup_ctx { > int dirfd; > __u64 resolve_flags; /* RESOLVE_BENEATH, RESOLVE_NO_SYMLINKS, etc. */ > __u64 op_flags; /* maybe future */ > }; > > setsockopt(fd, SOL_UNIX, UNIX_NEXT_LOOKUP, > &ctx, sizeof(ctx)); > > bind(fd, (struct sockaddr *)&addr, addrlen); > /* or connect(fd, ...) */ > > > Zero new syscall is needed. If this supports the `AT_EMPTY_PATH` no filesystem at all use-case (which is what I chose to highlight in the previous summary email), I'll take it --- it hits my desiderata. But implementation-side, I don't relish the thought of even more state for socket setup --- since we need to persist the lookup context until the bind. If setsockopt is the "ioctl of sockets" --- a convenient way to de facto create syscalls without doing so de jure --- I would think it would be better to just make it do the bind in one go so there is no state: struct unix_bind_anon_ctx { int *connect_fd; /* fd used to connect to this socket written to this */ __u64 op_flags; /* future usage */ }; setsockopt(fd, SOL_UNIX, UNIX_BIND_ANON, &ctx, sizeof(ctx)); Regular `linkat` can be used to place the "connect fd" in the filesystem for regular file-based connecting (e.g. to cope with long paths), in addition to how the "connect fd" can directly be used in the `AT_EMPTY_PATH` case. and for the connecting side: struct unix_connect_at_ctx { int dirfd; const char *path; __u64 resolve_flags; /* RESOLVE_BENEATH, RESOLVE_NO_SYMLINKS, etc. */ __u64 op_flags; /* SOMETHING_EMPTY_PATH, other future usage */ }; setsockopt(fd, SOL_UNIX, UNIX_CONNECT_AT, &ctx, sizeof(ctx)); This is just what I had in my previous `summary email`, but with the new system calls twisted into `setsockopt` variations instead. (I forgot to mention the `linkat` usage in that email, oops, but it was always intended to be part of the plan.) Cheers, John