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