On 12/9/25 06:04, Alyssa Ross wrote: > Alyssa Ross writes: > >> 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. > > (And also packaged by both Fedora and Debian.) Go ahead and use it then! -- Sincerely, Demi Marie Obenour (she/her/hers)