Quoting Chris G Demetriou,

> I'd say that not only is it unlikely that they were meant for
> inclusion in 1.2, but that they weren't even meant for 'immediate
> inclusion' in the non-1.2 branch of the source tree.

I started looking at this (well.. I did not have much time, so
it came down to telling Onno to work on it some more ;-))
originally for inclusion in 1.2, and to take an item off Charles' huge
TODO list, but it's obvious that it won't make it now.

> even on the i386 port, the changes supplied don't deal with the
> simple notion of not having any 'com' drivers in a given kernel...

Yep. That's a small fix though; include "com.h" in the i386 locore.s,
and add #if NCOM > 0 around the softtty entry.

> The notion of running the 'com' interrupt handler at IPL_HIGH makes
> little or no sense on machines where interrupt levels aren't as
> flexible as they are on the i386.

True. On the i386, using a 'high' interrupt level seems to be the least
ugly way to get decent serial performance, though. A solution would
be to define a seperate IPL_SER and splser(), which might be IPL_HIGH and
splhigh on the i386, but IPL_TTY and spltty() on the alpha. It would avoid
a #ifdef i386 in com.c, at least.

> On the Alpha, both "high priority" and IPL_TTY _have_ to block 'com'
> device interrupts (the former because that's what's meant by high
> priority, the latter because there's only one device interrupt level,
> and there could be other serial devices in the system).

> It should be obvious why this loses badly.

> It's worth noting that the current driver _doesn't_ have this problem,
> even though it defers processing to a lower priority level in much the
> same way, because the character input processing is done at splsoft().

Hmm, you mean that linesw[tp->t_line].l_rint() is inside an spltty()
protected section in the new driver, but not in the old one? I'm not
sure that his protection is even necessary in the new one (at first glance),
so that might easily be fixed.

- Frank