Subject: Re: devd-alike for NetBSD
To: Jachym Holecek <freza@liberouter.org>
From: Pavel Cahyna <pcah8322@artax.karlin.mff.cuni.cz>
List: tech-kern
Date: 02/08/2005 18:40:27
Hello,

> > 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

I understand the "human inspection" part. But the sysctl tree is not
directly human-inspectable either, and nobody seems to miss it.

Also, your format for <further-info> is unfortunately inconsistent.
The attribute names are different from the config(9) syntax. Returning to
your example:

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?

Also, it doesn't distinguish between PNP information and locators - for PCI,
dev and function are locators, but vendor and product aren't. (For USB,
vendor and product are also locators, so there is no problem.)
Maybe all the PNP information on all busses could be represented as
locators? This would solve this problem - /dev/drvctl could consistently
return locators only.

> 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.

s/BSGD/BSD/ of course.

> > 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? 

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.

Bye	Pavel