We (people at Gatespace & CR&T) have been thinking about how to get
IrDA support into NetBSD in a reasonable way.  One of the choices is
how much to put in the kernel.  The current suggestion is to put very
little in the kernel.  There needs to be a certain amount of kernel
driver support since the ways different chips are accessed are very
different.

Here's our proposal:

The interface between the kernel and user-land will be on the IrDA
frame level.  The system calls read()/write() are used to transmit
frames back and forth.  Each read/write handles one frame.  The kernel
driver and/or hardware will handle things like framing, checksums,
byte stuffing, etc.  The user-land will handle everything else, like
all the protocol levels above (e.g. IrLAP, IrMux, IrComm, ...)
To change things like link speed (and mode) there will be a small
number of ioctl()s.

We have user-land code (written by Tommy Bohlin) that handles the
lower protocol levels (IrLAP & IrMux) as well as the higher level
IrComm and IrObEx.  What this means in practical terms is that you
can transfer objects back and forth to, e.g., your Palm Pilot and
connect to the modem in your cell phone.

The kernel drivers will be split into two levels, one for the chip
level and one for the common API (much like the audio driver).
So you could have, e.g.,
  oboe0 at pci0
  irda0 at oboe0
  smc0 at isa0
  irda1 at smc0

The irda* devices show up as /dev/irdaNN device nodes and are used
by the user-land IrDA driver.

Comments?  Thoughts?

If people think this looks reasonable I can probably commit some drivers
soon.  And we can turn the user-land programs into a package.


--

        -- Lennart