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

Well, while I understand that having a common com code for all possible
architectures is a good idea, I'm not sure if it's a good idea to reject
an i386 com driver which clearly works better than the one we have now.
If the 'better' driver can't be used on Alpha, maybe the Alpha port
should have a different driver then.  Frankly, I couldn't care much less
about the Alpha serial ports - I'm responsible for six NetBSD/i386
machines, all having problems with FIFO overruns, while I have never even
seen an Alpha.

> I can't easily change either of those facts, and neither can i easily
> implement an ICU management scheme like the i386 port does, because
> ICU and interrupt management, for the most part, is handled below the
> level of the operating system software on the alpha.  (I don't know
> about other systems which could use the 'com' driver, but i could
> believe that to at least some degree that they could suffer the same
> problems as the Alpha does, in this regard.)

I understand this, but if the i386 can do better, why don't we let it?

> What this means is that these changes would actually _HURT_ serial
> performance on the Alpha (probably to the point of making high-speed
> communication impossible without hardware flow control).

Well, on the two pentiums I connected using a 115200 bps serial link,
communication _was_ impossible.  I guess if I had an Alpha, I might not
care about the i386, but..

> 	These changes enqueue data at "high priority" for later
> 	processing, and that later (character input) processing
> 	happens at IPL_TTY. 
> 
> 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.

I see.  BTW, why can't the i386 port enqueue the data at "high priority"
and do the later processing the way it's done now?  FIFO overruns happen
because the CPU isn't responding to UART interrupts fast enough.  The
main problem (as I see it) is getting the data out of the FIFO into a
largish buffer in RAM.  If this is done fast enough, the rest is not
all that critical.  Especially when using hardware handshaking, when
the system cann tell the other end to stop the transmission.

What happens with the current driver is that the system doesn't respond
to the UART interrupt fast enough and the UART has to discard one or
more bytes.  Also, because the (stupid) UART chips can't do automatic
hardware flow control, the RTS signal stays active all the time and
the remote system keeps transmitting more data (making sure that even
more bytes are lost).  IF the system responded to the interrupt fast
enough, it could also control the RTS signal in time to prevent data
overruns even when the higher-level RAM buffer is full.  This would
prevent overruns with modems completely because the current modems
are able to pass the flow control information to the remote computer.

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

Well, it may not have _that_ problem, but it sure does have a problem..

> And, to go back to
> the original point, about it being integrated now, for 1.2: changes
> which can seriously break system operation shouldn't be committed
> after feature freezes.

I agree.

This message was not intended to be a flame.  I just don't like the idea
of ignoring better working code only because there happens to be a system
where the same code doesn't work.  Glad that there isn't a Commodore 64
port of NetBSD.. if there were, we might be using a cassette drive for
swapping.  Phew, I want to see a working com driver on the i386 port! ;)

  -jm