Demi Marie Obenour writes: > On 12/9/25 05:55, Alyssa Ross wrote: >> Demi Marie Obenour writes: >> >>> On 12/8/25 19:38, Alyssa Ross wrote: >>>> This means we can use readiness notification to wait until the sockets >>>> are created without having to add special functionality for that to >>>> the router program, and also means we can do extra system-specific >>>> setup to the sockets, like changing their owners, outside of the >>>> router. >>>> >>>> Since the socket paths were the only arguments taken by the router, >>>> this also lets us drop the clap dependency entirely. >>> >>> I strongly recommend open-coding the file descriptor stuff instead >>> of using a third-party library for it. It's just a two calls to >>> getsockopt() (SO_DOMAIN and SO_TYPE) per socket, and listenfd pulls >>> in wasm-bindgen and js-sys! >> >> It pulls in wasm-bindgen and js-sys if you're building for those >> platforms, which we are not. An inert mention in Cargo.lock is not a >> problem. The only dependency of listenfd in our context (checked via >> cargo tree) is on libc, which is already a dependency of tokio. >> >> I've implemented systemd socket activation in Rust before, and it's not >> at all nice, even with libsystemd. listenfd adds 295 extra lines of >> code in total. I think that's worth it. > > Ah, I didn't mean to actually implement the whole thing, but rather > to open-code the specific case used here. > > If listenfd is a very popular crate, I'd go with it. Otherwise, > I'd be too concerned about supply-chain risk. On the other hand, > I might be too used to having to use Fedora and Debian packages for > my Rust dependencies. "#28 in Unix APIs", ahead of landlock and just behind libseccomp.