>Actually, as I think about it, I'll have to make this a conditional, since
>I can't think of a convenient way to poll for the IR transceiver format
>(though if you were willing to, say, strap the internal Carrier Detect or
>Ring Indicate pins to the opposite of their default state, we could perhaps
>set a standard for this to be automatically polled versus a standard
>SHARK).

Hmmmm .... I haven't really thought that far yet.  My other concern is
that the National chip that the Shark uses is also used by i386 PCs
(and I happen to own one of those as well) so keeping this generic
as possible is a win.

>There is one <big> potential downside, depending on the application you are
>using.  Since I steal the handshaking lines from the UART, it was necessary
>for me to either completely rip apart the COM driver, or to create a new
>one, and I've sort-of taken the second route.  However, the RS-232 code is
>basically just a data transfer routine; it does not do any TTY stuff, nor
>H/W or S/W handshaking, etc.  It really is assumed that the serial port
>will be used for control applications which want control over how data is
>passed back and forth...  would this be OK for you?

Well, IrDA _does_ want to do things like set baud rates, etc etc, but
not flow control.

My thinking was that it might make the most sense is to extend the
current com driver with ioctl's to know about the extra IR stuff.
I'll confess this was all motivated by IrDA, and I know the consumer
stuff generally has a different interfaces, so it may not make sense,
but I would still advise to at least try to do that as much as possible.

>As I haven't done <any> IOCTLs yet, I especially appreciate the early
>warning here - in particular since the code has to do one <bad> thing, by
>checking the absolute port address to determine if the "capable" UART or
>the "stupid" UART is being attached - fortunately, that's done only once,
>and from then on a flag determines what else happens...  Similarly, the
>devices are initialized by a simple port:value list, so that'll be easy to
>do...
>
>In other words, if your appplications do basic "raw" I/O, OK!  Would you be
>willing to add the internal wire?

I'm in a sort-of weird category to begin with, so it may not make sense
to even allow for me in your code.  I have a dumb question, though ...
it sounds like you had to make hardware changes to the Shark.  Was the
onboard stuff not enough?  Or am I misunderstanding you?

--Ken