Hello,

> > Yes, the format is textual: "<event> <device> <further-info>". It seemed
> > like the most powerful representation. The textual messages are intended
> > for 1) human inspection 2) event demon that uses regular expressions
> 
> I understand the "human inspection" part. But the sysctl tree is not
> directly human-inspectable either, and nobody seems to miss it.

Fair enough. If binary format is preferred, I'll move towards one
when I'm "finishing" the thing. For development, text format is better.

> attach uhub0 at usb0 port 0 config -1 iface -1 vendor 8086 product 0000
> 
> but usb(4) says:
> 
> uhub*   at uhub? port ? configuration ? interface ? vendor ? product ?
>            release ?
> 
> (look at the difference: config vs configuration and iface vs interface.)
> If text-form is finally approved, could this be made consistent, please?

Note that we often have to differ from autoconf -- it translates
product/vendor IDs and hides some low-level attachment hints. But
consistency is certainly a requirement, I'll fix that.

> > > BTW what does FreeBSD newbus do?
> > 
> > Text form. Unlike newbus, we allow "dd if=/dev/drvctl of=/dev/stdout bs=1".
> 
> They don't allow this? So their interface is text form and record-oriented,
> where record = line? 

From $FreeBSD: src/sys/kern/subr_bus.c,v 1.168 2005/01/19 06:52:19 imp Exp $

/*
 * The read channel for this device is used to report changes to
 * userland in realtime.  We are required to free the data as well as
 * the n1 object because we allocate them separately.  Also note that
 * we return one record at a time.  If you try to read this device a
 * character at a time, you will loose the rest of the data.  Listening
 * programs are expected to cope.
 */
static int
devread(struct cdev *dev, struct uio *uio, int ioflag)
{
	[...]

> Another question: how to represent insertion of "not configured" device?
> This would be needed if a daemon should find an appropriate LKM driver for
> it and load it. AFAIK, that's what Linux 2.6 does and probably it's the
> only way to make drivers work as LKMs.

"unsupported on <parent> <locators+pnp>" ?

Note that attach events describe "interesting parts" of <bus>_attach_args,
so there's enough information to fabricate attach to given device later,
after LKM would be loaded (not sure there is actually some tool for this).

	Regards,
		-- Jachym Holecek