Excerpts from mail: 16-Feb-98 Re: The role of OpenFirmwar.. Markus
Illenseer@core.de (511*)

> > I've been looking at this, and I think I've come to a conclusion.  It seems
> > that it should be possible to move all openfirmware calls to one place in
> > the very beginning of the kernel, or perhaps even in the booter once I
> > figure out what the heck I'm doing wrong with it.

>  I am not sure if I really groke the idea. Currently there is no native
> SCSI driver for my PowerPC-System, hence I am depending on OpenFirmware
> all the time, not only at boot time. I do not have a PowerMac.

Dan,

(Maybe I'm still living in a CHRP dream :-)

As a bit of revision, the openfirmware/chrp model is roughly as follows:

	o	machine boots open-firmware

	o	open-firmware loads kernel image

	o	kernel image uses device-tree to
		determine device drivers that need to be
		loaded.

		NB: If no device driver is available, the OF
		interface to the device can be retained as a
		slow fallback.

		NB: Since the device tree provides a complete
		description of the hardware there shouldn't be
		any need for the driver code to probe the device/
		bus.  Interesting idea this!

	o	If device drivers for all devices are found
		_then_ openfirmware can be unloaded and
		the OF resources reclaimed.

		NB: Of course, one could force an unload if
		the device that wasn't found was, say, a
		sound card :-)

	o	regardless of the state of openfirmware
		the machine also provides a light weight
		`RTAS' (pronunced ratsac?) (run-time
		abstraction services).  These services
		include primatives such as machine halt.

Consequently, the OF calls can't be isolated to the boot code.   Since
the kernel can't unload a staticly linked driver, there will probably
always be at least the text of the OF-driver around.  Of course, if the
kernel could unload such device drivers, ... :-)

	make sense?

		enjoy,
			Andrew


--

Why is it that my 486 can boot MINIX in less than a second :-^