> > $ cat /dev/drvctl
> > attach cpu0 at mainbus0 
> > attach acpi0 at mainbus0 
> > attach acpiec0 at acpi0 
> > attach acpibut0 at acpi0 
> 
> So, /dev/drvctl presents events in a text form? Is this a good idea? In
> Linux procfs, most of the nodes are human-readable text and it seems to do
> much more harm than good. E.g. "trivial" whitespace changes breaking
> userspace programs.

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
for match -- I hope ("well written") regexps to be resistent against
trivial changes.

[Also, message format is not supposed to change, once "finished".]

> I always preferred the way how sysctl in BGSD presents structured binary
> information.

I'll have a closer look. So far, textual format has made life simpler
for me.

> BTW what does FreeBSD newbus do?

Text form. Unlike newbus, we allow "dd if=/dev/drvctl of=/dev/stdout bs=1".
It's nothing really important, but I think it's a little more userland
friendly. Like newbus, we only meaningfully support one reader.

> Also, OpenBSD has /dev/hotplug which presents the events as simple
> structures:
> 
> http://www.openbsd.org/cgi-bin/man.cgi?query=hotplug&sektion=4&apropos=0&manpath=OpenBSD+Current&arch=

Hmm, they basically dump "struct device" as it seems. They are unable to
pass any PNP information about the device, which limits usability I think.
With this approach, it could end up like:

	struct dvannounce {
		char 		name[...];
		...
		union {
			struct pci_attach_args 		pci;
			struct pcmcia_attach_args 	pcmcia;
			struct usb_attach_args 		usb;
			...
		};
	};

That seems less extensible and more fragile then textual format. Plus
the demon would need to be updated every time you added a new bus...

	Regards,
		-- Jachym Holecek