Jonathan said:
> [ Chris Torek said: ]
> >  There are also some really horrible gross
> >bootstrap cases (like console serial ports) where you may decide to
> >do static allocation of certain structures instead of the `clean' (?)
> >solution of having a software layer to make the hardware look like
> >it was designed sanely in the first place, but again this is really
> >just a case of expediency.
> 
> I have to disagree with the last half of that sentence.
> 
> Even with sanely-designed hardware, consoles are a `problem child' for
> the autoconfiguration code.  One needs a console device, for console
> output, even before malloc() is even up.  In other words, one needs
> the console device before the `clean' autoconfig code is even
> *callable*, let alone before the normal order in which the console
> device would be found by autoconfig. (I assume the latter is what you
> mean by a `sane software layer'?).
> 
> This is a bootstrapping problem, and as such it's completely
> orthogonal to the sanity of the hardware design of the console
> interface.  (It's a problem inside the software architectural structure.)
> I've run into it even with relatively sane serial console hardware.

I think Jonathan's right here.  You actually run into this for all
types of console devices, be they serial, "glass tty" on frame buffer,
or whatever, if you have to initialize the device and be able to do
console output before 'malloc' works.

Realistically, this problem can be dealt with simply for most devices:
add a level of indirection.  8-)


In NetBSD/alpha, for most console-capable devices, the general scheme
goes something like:

	define a struture that includes whatever configuration
	    information, etc., the device needs at console init
	    time if it's the console.

	put a pointer to that in the softc, along with any other
	    information you might need, but will never need at attach
	    time.

then, statically allocate one of the former structures, and use it if
the console device happens to be that device.

when units of the device are 'attach'ed, if they're the console device
(there can be only one! 8-) the static structure is pointed to by the
softc pointer.  If not, either another structure is malloc'd, the
pointer can be pointed to an area of the softc that contains one of
the structures.  (For the softc of the console device, the structure
would be unused.)


Sure, it's an extra pointer indirection and a bit of wasted space, but
it reduces the complexity of the console-attachment code by a fair
amount, and the run-time cost isn't very high.


This becomes more complex, of course, when dealing with resource
allocation schemes, but it's still doable.  (One screw, in particular,
that's annoying to me is that i'd like to be able to have the MI PCI
code allocate regions of PCI config space and hand ownership of the
regions to the devices which own them (at attach time).
unfortunately, since console attachment/allocation handling is a very
device-dependent issue, that's more or less impossible...)



chris