Hi,

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

Hmm, I'm in this CHRP/OpenFirmware dream, too (you guessed that, didn't
you? :-)), albeit I'm a bit disappointed by the things happening on this
front recently :-(.

Anyway, a few comments to your statements:

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

As is done for all devices in the current NetBSD/powerpc implementation.

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

It would be ideal, if OpenFirmware would really provide this service.
Unfortunately the OpenFirmware working group has weakened this concept by
allowing (requiring?) an implementation to _not_ probe all devices on some
busses :-(.

E.g. if an implementation finds a SCSI bus, it only has to provide one
generic disk and and one generic tape node and be done with it.  The user
then has to specify unit addresses (= SCSI IDs) when actually accessing
a disk or tape.  There is no probing done on the SCSI bus whether there
actually is a disk or tape on the bus, nor whether there are any other SCSI
devices.

Yes, I _do_ think that this is a severe bug in the specification.

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

If you don't need OFW for anything else.  You might want to use OpenFirmware
for debugging purposes (a complete implementation does include a debugger),
or you might need it for halt/reboot services (if you don't have the CHRP
RTAS available or that doesn't provide the flexibility that OFW does).

> 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, ... :-)

For quite some time I'm running a kernel that can free statically allocated
space even after boot.  Ok, I'm not using it to unload device drivers (this
would require some additional hackery to eliminate the driver from it's
various interface tables), but only for freeing the space that the kernel
symbol table occupies after booting (in case anyone cares, I'm swapping
the symbols out if they are not used for DDB, but only for /kern/kernel).

Shouldn't be too hard to free the space of some drivers, albeit I'm not
sure whether this really buys you a lot, as these OFW-drivers aren't
particularly large (text+data+bss: ofbus.o: 720+64+0, ofcons.o: 2184+32+8,
ofdisk.o: 2288+36+0, ofnet.o (which includes support for remote gdb):
3004+44+1780, ofrts.o: 1312+32+0).

Since you can only reuse space easily that is page aligned, you would have
to be lucky so that all drivers you want to unload were put sequentially
into the kernel, and even then you would at most be able to reclaim 2 pages.
Compare this to the code needed to actually do the unloading...

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800