On Sun, 4 Mar 2001, Ignatios Souvatzis wrote:

> NetBSD/Amiga can have a several different console output devices:
> ser at mainbus (on non-DraCo), ite at grf at grfcc0 at mainbus (on
> non-DraCo), and ite at grf at grfFOO at zbus at mainbus.
> 
> Also, it can have several different CPUs at several different speeds and
> needs to calibrate the delay() routine before (some of the) drivers are 
> initialized.
> 
> NetBSD-Amiga does this:
> 
> - before console selection, it runs a fake autoconfiguration pass on busses
>   that can have a console device, and for the clock (that does the delay
>   calibration) and ser mainbus devices.
> 
> - during this pass, devices get a NULL variable storage area, and use a 
>   static one if they decide the might be a console.
> 
> - now console selection happens.
> 
> - after this, real configuration happens. Instances of devices that know
>   they are a console don't reinitialize, but copy their early config state
>   to the new device struct.
> 
> This happens in the config_console() and amiga_config_found() routines 
> in amiga/amiga/autoconf.c cited below for your convenience. Some knowledge
> of this is in amiga/dev/zbus.c, and obviously in the clock, grf* and ite*
> drivers. 

Why do things this way?

As I understand it, every device, even ones which which would never be the
console device, need to tell the difference between the fake and real
config phases. That's a fair bit of overhead.

Might I suggest doing thins more like how mac68k and other do? Each
sonsole device fills in a struct consdev and shoves them in an array
constab. The cninit() routine, in sys/dev/cninit.c, steps through each of
them and calls its probe routine. From this, it determines the best fit
for the console.

The advantage of doing this this way is that only the console-capable
devices get probed, and all of the normal config routines don't have to
tell which probe case they are in. Oh, and you could add a fake console
device, whose probe always reports CN_DEAD (don't use me), as a way to
perform the clock calibration.

The one drawback to using cninit() is that the graphical devices would
need to figure out where they were w/o the benefit of the bus to which
they are attached. I'm not sure how much of a problem that is.

Take care,

Bill