From: Claudio Jeker Subject: Re: imsg_get -> imsgbuf_get To: Theo Buehler Cc: Kyle Ackerman , gameoftrees@openbsd.org Date: Wed, 29 Jul 2026 09:34:48 +0200 On Wed, Jul 29, 2026 at 09:09:22AM +0200, Theo Buehler wrote: > On Tue, Jul 28, 2026 at 10:40:19PM -0600, Kyle Ackerman wrote: > > some recent commits to OpenBSD brought to my attention we may could use > > a better function to test if get get a new imsg in some of our IPC > > functions. Currently, we mainly use imsg_get to test if we got a new > > message. This function returns the length of the message written. We > > could use imsgbuf_get which just returns the status of if the message > > was written. This doesn't save any meaningful amount of time, but may > > be the more correct function since in many cases we don't actually do > > anything, other than to test if there is a failure or no new messages, > > with the return value of imsg_get. > > Thank you. claudio will remove imsg_get() from libutil soon. "soon", still a lot to fix first. Still I want to land this before the next OpenBSD release. > ok tb > > for your diff. Also OK claudio@ > As you noticed, and it is essentially true in general, that nothing > really uses the actual length return value of imsg_get(). The few uses > of it (like in sbin/mountd) first have to fiddle with IMSG_HEADER_SIZE > to get to the info and data they actually want, which shows that > imsg_get() is not a great interface. IMSG_HEADER_SIZE is a libutil > implementation detail applications should not need to know about and it > should eventually become internal to libutil. > > It would generally be desirable if got could make more use of the new > imsg API like imsg_get_type() and imsg_get_len() in libutil and stop > reaching into struct imsg directly: longer term struct imsg should > become opaque. Getting there is going to take a lot of thankless, boring > churn and the conversion should not be rushed, as it is easy to introduce > errors along the way. > > The imsg_get() -> imsgbuf_get() conversion is one small step towards > such long term goals, which should result in safer use of imsg and > better privsep hygiene by introducing better programming idioms. This is a very good summary. The goal is to provide a better API on the read side. There are now arious getters that work for the simple case but can also be used for more complex messages (imsg_get_data vs imsg_get_buf, imsg_get_ibuf and imsg_get_strbuf). My long term goal for the reader side is to remove imsg.data and force everyone to use imsg_get_xyz. That way all access includes proper bound checks. On the send side it seems every tool tries to just pass everything through imsg_compose() which is less then optimal. Using imsg_create plus imsg_add / ibuf API is not pleasant. imsg_composev is also very special and the use is less than trivial. That part is very much open and any input is appreciated. -- :wq Claudio