On Tue, Oct 24, 2023 at 04:00:42PM +0200, Claudio Jeker wrote: > On Tue, Oct 24, 2023 at 03:50:47PM +0200, Theo Buehler wrote: > > On Tue, Oct 24, 2023 at 03:01:26PM +0200, Claudio Jeker wrote: > > > When I added ibuf_get_fd() the idea was to make sure that ibuf_free() will > > > close any fd still on the buffer. This way even if a fd is unexpectedly > > > passed nothing will happen. > > > > > > That code was disabled at start because userland was not fully ready. In > > > particular rpki-client did not handle that well. All of this is to my > > > knowledge fixed so there is no reason to keep the NOTYET :) > > > > > > With this users need to use ibuf_fd_get() to take the fd off the ibuf. > > > Code not doing so will break because ibuf_free() will close the fd which > > > is probably still in use somewhere else. > > > > Nothing in base outside of libutil seems to reach directly for the fd > > (checked by compiling with that struct member renamed in the public > > header). > > > > The internal uses are addressed by this diff, so > > > > ok tb > > > > I can put the fd rename through a bulk to catch some ports in a couple > > of days but I don't think there is a need to wait. > > Thanks. Do we have a list of ports that use ibuf / imsg?
I don't think so. The list of ports using libutil is rather long. my sql is nonexistent but I get a few hundred.
