Subject: Re: Documentation for autoconf system
To: None <jdolecek@netbsd.org>
From: None <jkunz@unixag-kl.fh-kl.de>
List: tech-kern
Date: 04/21/2001 16:57:55
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. And figureing out
implies assumptions. These assumptions my cause bugs... So I see a need
for autoconf(9). Fortunately there are bus_space(9), bus_dma(9), disk(9)
(where is tape(9)?), uvm(9), ... that explaining these important,
general systems. But no autoconf(9). No I will not write it. I have to
less knowledge about kernel hacking and the english language to do
this. But I plan to rewrite vax/ts(4) and I will write a litle doc
about how it was done to help other novice kernel programmers. 

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

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

> 	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. (*)

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

> 	(commonly, the location and configuration information is
> 	passed by the attach tag).
Seems that my assumption (*) is correct?

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

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



tschuess,
          Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz