> Would be cool if this was in 1.2.

"Cool" is not the word that I would use.  Looking at these patches,
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.


We've now passed the point of 'feature freeze' for the 1.2 release.
If this driver were to go in now, I, the maintainer of the Alpha port,
would have to add:
	(1) 'soft' tty interrupt handling code to my kernel,
	(2) some way to deal with the ... interesting assumptions made
	    by the driver, if they can be handled at all.

Neither is acceptable after a feature freeze.  There's also the fact
that, 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...


What i mean by the 'interesting' assumptions made by the driver:

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.

On all Alphas i've seen so far:
	(1) there's no way to reassign the interrupt priority for a
	    given device,
	(2) all devices interrupt with the same priority level.

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


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).  The problem
is a simple one:

	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.


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


While i'd like to say, "I hope that problem is fixed before the driver
is committed," it's much more serious than that...  If the problem
isn't fixed before it's committed, then a whole class of users will
more or less lose the use of their serial ports.  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.




cgd