John Fremlin wrote:
> I did a bit of driver writing for the linux kernel, but I'm finding
> doing a port of NetBSD to Psion 5 MX PDA somewhat hard going, mostly
> because I'm struggling to understand how the kernel fits together. ATM
> I'm trying to get either the serial port (preferably) or the
> framebuffer working.

BTW, you might find usable the md(4) stuff used for root for INSTALL
kernels, too.
 
> How is the autoconf device detection stuff supposed to work? (Which
> functions call what expecting what?)

That exactly do you need?

The autoconf machinery is quite simple once you figure out the way
it works. If you want to ignore the exact details of how the device
probe tree is built and walked on runtime, the bits needed for
each individual "leaf" driver are like this:

1) each driver specifies a structure holding three things - size
	of it's private structure, probe function and attach function;
	this is compiled in and used in runtime - example:
	
	struct cfattach foo_baz_ca = {
		sizeof(struct foo_baz_softc), foo_baz_match, foo_baz_attach
	};

2) on kernel startup, once the time comes to attach the device, autoconf code
	calls device's probe routine and passes it pointer to parent
	(struct device *parent), pointer to attach tag structure
	(void *aux), and appropriate autoconf node (struct cfdata *cf)
	The driver is expected to find out if it's where it's supposed
	to be (commonly, the location and configuration information is
	passed by the attach tag). If yes, the probe routine should return 1.
	If device is not there, probe routine has to return 0.
	NO STATE SHOULD BE KEPT in either case.

3) if probe returned success, autoconf allocates chunk of memory sized
	as specified in device's *_ca and calls it's attach routine,
	passing it pointer to parent (struct device *parent), pointer
	to the freshly allocated memory (struct device *self) and the
	attach tag (void *aux). Driver is expected to find out exact
	ports and memory, allocate resources and initialize it's
	internal structure accordingly. Preferably, all driver instance
	specific information should be kept in the allocated memory.

Example - let's have an PCI ethernet device 'baz', kernel config
chunk looks like this:

pci*	at mainbus?
baz*	at pci? dev ? function ?

On runtime, autoconf iterates over all physical devices present on
machine's pci bus. For each physical device, it iterates over all
devices registered in kernel to be on pci bus, and calls drivers'
probe routine. If any probe routine claims the device by returning
1, autoconf stops iterating and does the job described under 3).
Once the attach function returns, autoconf continues with next
physical device.

Feel free to ask further :) I hope the description was not too
confusing.

The autoconf scheme has couple of advantages over the Linux
every-device-does-it-itself scheme. I admit it's a bit more complex,
but it has quite a few important and useful features too.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
NetBSD - just plain best OS! -=*=- Got spare MCA cards or docs? Hand me them!