In article <200104211457.f3LEvtd00747@unixag-kl.fh-kl.de> you write:
>On 20 Apr, Jarommr Dolecek wrote:
>> The autoconf machinery is quite simple once you figure out the way
>> it works.
>Figuring out is the probem. Every one has to reverse engeneer existing
>drivers if he wants to know how to write a new one.

Well, you can always read the code in subr_autoconf.c that runs it all. 
That certainly helps if you're writing a bus driver, rather than just a leaf
device.

>> 1) each driver specifies a structure 
>Is the name of this  structure by convention foo_ca if the driver is
>named foo? Who tels the kernel code about how this structure is named?
>config(8) and the autoconf frame work?

Indeed.  The name is either foo_ca, for an attachment declared as "attach
foo at bar" or foo_bar_ca for an attachment declared as "attach foo at bar
with foo_bar".

>> 	pointer to parent (struct device *parent), 
>What is the parent of a device? The bus it is pluged in? (scsi bus
>driver (scsi adaptor driver?) for a scsi disk, pci bus driver / attach
>code for a PCI card?

Yes.  In the example above, it'll be a pointer to the "bar" device to which
this "foo" is attached.

>> 	pointer to attach tag structure	(void *aux),
>What is a attach tag structure and what is it used for? Reading
>dev/qbus/rl.c it seems that the autoconf frame work passes some
>bus_space tags / handles to the match routine and the match routine
>has to perform the device probe on this bus_space tags / handles. This
>attach tag structure seems to bee highly bus type dependend. (*)

It is indeed.  This is why you have a separate match and attach routine for
each bus.

>> and appropriate autoconf node (struct cfdata *cf)
>Is that the same structure previously defined in step (1)? 
>(struct cfattach foo_baz_ca = ...)

No.  One's a struct cfattach, the other's a struct cfdata.  The struct
cfdata is the internal representation of a line of a kernel config file
(like "foo* at bar? slot ?").

>> On runtime, autoconf iterates over all physical devices present on
>> machine's pci bus.
>Is that valid for other busses too? The driver does not scan the entire
>bus for devices it my support. The bus scan is performed outside the
>driver in the autoconf code. The kernel detects "some" hardware and
>iterates over the registered devices to find a suitable driver?

That's the case for those busses where this is possible (PCI, SCSI,
podulebus).  For busses where the autoconf code (actually, the code in the
parent driver) can't work out what's there (e.g. ISA) things work a little
differently, but I'm afraid I don't know quite how.

>> 	pci*	at mainbus?
>> 	baz*	at pci? dev ? function ?
>And apropriate lines in dev/pci/files.pci?

Yes.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>