> I have a feeling it was simply easier to have code for a single console.
> Also, having 'dt' in userland does make it somewhat easier to maintain.

This is probably correct.

> I'm not entirely sure what kind of gain you'd see from having it in the
> kernel.  You could probably hack it to run at startup if you want it that

Two words: faster draws. When dt runs as a user land proc the graphics
routines get blocked repeatedly when the system switches processes.
When the console code runs in the kernel it can only get interrupted
by hardware interrupts.

A good example of this is the screen clearing code. You can actually
watch the screen clear on dt when it starts or is under some other
suitably high system load.

You may be ask then, why ite is so slow compared to dt. THis is
because ite is coded for generality and not for speed. The code
in dt is fairly well optimized for 1 bit mode (check out
the funky UNROLL macro at the top of it's blit mode).
If you avoid these optimizations and some of the function in-lining
then dt will run almost as slow as ite.

How do I know? I ported the dt code as a soft console for a OS
project I did a long time ago. The compiler we were using was
quite old and hadn't heard of function inlining and didn't
grok the UNROLL macro. Take those things away and it was quite
slow (the 68010 didn't help either :) ).

> > Another minor problem might be to handle the special case where there is
> > no local console (i.e., running headless). AFAIK dt doesn't handle this
> > well at all.
> 
> Well....in that case, the grf devices probably wouldn't configure 
> correctly, so it wouldn't be all that bad, I wouldn't think...of course, I
> don't know that much about our grf devices, so take all I've said with a
> grain of salt :-)

Dt seems to assume one grf and 1bit mode. Dealing with the more complicated
systems we have today is simply a matter of adding more intelligent checks.