On 12/9/25 06:01, Alyssa Ross wrote: > 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. Okay :) -- Sincerely, Demi Marie Obenour (she/her/hers)