>1) disable use of hardware FIFOS.  Set the UART into
>interrupt-per-character mode and actually take the interrupts.  This
>avoids jamming the timecode from the clock into one stream, serviced
>by one (or at most two) interrupts. which is a *bad* thing for this
>application.

AFAIK, the com driver (which I believe is the only supported UART
that has a hardware FIFO) already does this for lower baud rates;
anything 1200 baud or lower, it sets the fifo trigger to 1.

>And again: For the special case of x86 and a GPS with PPS, just using
>the parallel port for PPS (or the DCD timestamp patch) is good enough.
>And though this is cool stuff to timevultures, I'm still not convinced
>the population of radio-clock users is big enough to justify this.
>Unfortuntely, till now NetBSD hasnt had adequate support for radio
>clocks, so the interested people are all off using some other OS, so
>theres really no way to tell.

Well, I hope that projected user base isn't the only criteria used for
inclusion :-)  I think that if it doesn't impact anyone else, and it
could be used by someone else (and it sounds like there would be at
least two users :-) ), then why not put it in?  Of course, that
decision isn't up to me.

--Ken