Subject: Re: IrDA?
To: Jukka Marin <email@example.com>
From: Ken Hornstein <firstname.lastname@example.org>
Date: 01/29/1999 02:00:44
>If IrDA isn't supported, has anyone played with the real IrDA protocol
>before? I have written software for IrDA hardware, but using only a
>custom protocol (ie. hardware is IrDA compatible, but software isn't).
>I wonder if IrDA protocol could be implemented as a user-level protocol
>or if kernel support would be required..
I looked at IrDA support a little while ago, and spent a vacation poring
over the documentation (it was more fun than it sounds, actually). Here's
my take on it:
- The hardware is available in lots of things (nearly all recent laptops)
and almost always looks like a serial port at the simplest level.
If the hardware supports the faster IrDA modulations (FIR, up to
4 Mbps), then you need to talk to the chip in funky ways, but for the
SIR modulations are always done just by treating the UART as a UART
(modulo some strange initialization stuff you have to do if you're
using something like the National chipset the Shark uses). For instance,
I logged onto chopps's laptop at the last IETF by simply having him
run a getty on his IrDA com port and I tip'ed over (sick, I know, but
I didn't have a WaveLan card :-/).
- The protocol itself is ... unusual, and is definately designed by
committee, but it not unreasonable considering the hardware
constraints (half-duplex and the receiver is squelched during
transmit). All of the protocol is available via www.irda.org.
- While the protocol specification was rather convoluted at parts,
each section included a full state machine for that particular part
of the protocol, and the documentation basically said, "We recommend
you implement the state machine". If you look at the Linux code,
that's exactly what they did. So you could (in theory) write IrDA
code without understanding the protocol :-)
- The timings are all negotiable, and IIRC the worst-case was that you
had to respond by 500ms. Easy doable in user space.
- If we were going for full NetBSD integration, it seemed to me that the
best thing to do was to create a netirda directory and implement
IrLAP and IrLMP in there (those are the hard ones) and create
a PF_IRDA socket family and IRPROTO_PHY, IRPROTO_LAP and IRPROTO_LMP
protocols. A line discipline would bind a serial port to an IrDA
interface, much like the way ppp works now.
So I think it's reasonable to do .... just a SMOP :-)
As to whether or not Bluetooth will kill it, too early to tell. It
looks cool, but I'll wait until it hits the streets, and I see the
nasty spectre of "Intellectual Property" all over the web site.