IrDA
Lennart Augustsson
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
Jukka Marin
> The irda* devices show up as /dev/irdaNN device nodes and are used
> by the user-land IrDA driver.
>
> Comments? Thoughts?
Sounds pretty good to me. :-)
> If people think this looks reasonable I can probably commit some drivers
> soon. And we can turn the user-land programs into a package.
Will you write drivers for external IrDA adapters like Ir-Mate 210 which
connect to any serial port? (I've got the IrMate programming doc if you
need it.)
-jm
Lennart Augustsson
There will be a driver for IrDA on serial ports. A problem is that different
adapters need to be handled slight differently when e.g. changing speed.
One way to handle serial ports is to do it all in user-land code, an alternative
is to use a different line discipline for IrDA and access it through /dev/irdaNN.
Either way, the problems above is present.
--
-- Lennart
Lennart Augustsson
> On Thu, Jul 20, 2000 at 09:19:57PM +0200, Lennart Augustsson wrote:
> > 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
>
> I can see having transparent com* support as being a big plus. I
> don't know much on the technical side of IrDA, so I'm not sure if
>
> irdacomm0 at irda1
> com0 at irdacomm0
>
> would be the best way or if it could be a direct
>
> com0 at irda1
We've been discussing these things. Something like this can certainly be
done, but it's not entirely clear exactly how. (One problem is that IrDA
attachments are very transient; they can come and go easily. Should the
device persist or not?)
For now the idea is to have it all in userland and allocate a pty for IrComm
devices. As things progress we can migrate things into the kernel.
--
-- Lennart
Nathan J. Williams
> 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.
Does this mean that accessing devices over IrCOMM will be different
than accessing a normal serial device? For example, how would one run
getty(8) over IrCOMM?
- Nathan
Lennart Augustsson
You can use a pty to make it look the same. (From one side, at least.)
Having everything in user-land is probably not the final solution to handling
IrDA, but it's a start. (It's also nice because it allows easier debugging.)
--
-- Lennart
Ignatios Souvatzis
> You can use a pty to make it look the same. (From one side, at least.)
>
> Having everything in user-land is probably not the final solution to handling
> IrDA, but it's a start. (It's also nice because it allows easier debugging.)
Which makes we wonder: has anybody evaluated "netgraph"?
Regards,
-is
Ignatios Souvatzis
> What about IP over IrDA? How does your mechanism handle something like
> that?
tunnel device?
-is
Jason R Thorpe
> Comments? Thoughts?
Rad! :-)
What about IP over IrDA? How does your mechanism handle something like
that?
> If people think this looks reasonable I can probably commit some drivers
> soon. And we can turn the user-land programs into a package.
Why not put the tools into the source tree?
--
-- Jason R. Thorpe <tho...@zembu.com>
Ken Hornstein
I had looked at this for a while some time ago. It really seemed to me
that the "right" thing to do was to put things like IrLAP and IrLMP
into the kernel (since those are the "per interface" things) and have
userland programs create a PF_IRDA_LMP socket (or whatever you wanted
to call it). But since I never did anything, your approach sounds fine
:-) At least that would get us to start playing with some IrDA code ...
maybe the next level would be to bring it into the kernel. Might be
tricky to do IrLAN without kernel support (but I guess you could use
the tunnel device).
BTW, what's IrMUX?
--Ken
Lennart Augustsson
> On Thu, Jul 20, 2000 at 09:19:57PM +0200, Lennart Augustsson wrote:
>
> > Comments? Thoughts?
>
> Rad! :-)
>
> What about IP over IrDA? How does your mechanism handle something like
> that?
Well, AFAIK there's no standard for how that should be done. There's IrLAN
that I don't who's actually using.
For point-to-point, which is the most likely situation, I would use IP over PPP
over IrComm. That's what we used for connecting to the internet via cell phones.
> > If people think this looks reasonable I can probably commit some drivers
> > soon. And we can turn the user-land programs into a package.
>
> Why not put the tools into the source tree?
Sure, if people prefer that.
--
-- Lennart
Lennart Augustsson
> >Comments? Thoughts?
>
> I had looked at this for a while some time ago. It really seemed to me
> that the "right" thing to do was to put things like IrLAP and IrLMP
> into the kernel (since those are the "per interface" things) and have
> userland programs create a PF_IRDA_LMP socket (or whatever you wanted
> to call it).
Yes, that's certainly a viable alternative.
> BTW, what's IrMUX?
Maybe that's not what it's called. I've not the one who's been reading the
IrDA specs. The IrDA multiplex layer. Is it IrLMP?
--
-- Lennart
Jason R Thorpe
> On Thu, Jul 20, 2000 at 01:53:49PM -0700, Jason R Thorpe wrote:
> > What about IP over IrDA? How does your mechanism handle something like
> > that?
>
> tunnel device?
Yuck, copying packets across protection boundaries! :-)
Lennart Augustsson
> However ... I saw some pages that imply that Windows 2000 ditched IrLAN
> and IrCOMM for something they created called IrNET (which there isn't
> a standard for).
The joys of Micro$oft. :(
--
-- Lennart
Ken Hornstein
>> that?
>
>that I don't who's actually using.
There are those little things that HP sells (NetEye?) that are approximately
$200 US and do IrLAN. Uh, well, there _used_ to be something like that ...
maybe they don't sell it anymore.
Ah, wait, I'm wrong (it was "JetEye", and it wasn't made by HP):
http://www.extendsys.com/products/infrared/jeteyenet.html
However ... I saw some pages that imply that Windows 2000 ditched IrLAN
and IrCOMM for something they created called IrNET (which there isn't
a standard for). And I'm not completely sure this box isn't PPP over
IrCOMM (but I really do remember that the JetEye was IrLAN).
--Ken
Ken Hornstein
>
>Maybe that's not what it's called. I've not the one who's been reading the
>IrDA specs. The IrDA multiplex layer. Is it IrLMP?
Yes, that's IrLMP. Sorry, I was just wondering what this new protocol
was :-)
--Ken
Hubert Feyrer
> One way to handle serial ports is to do it all in user-land code, an alternative
> is to use a different line discipline for IrDA and access it through /dev/irdaNN.
> Either way, the problems above is present.
Will there still be a /dev-node then that I can hand to
pppd/kpppd/kermit/whatever to do the modem control etc., or
will interfacing with a different method be required?
It would be nice if there was some /dev/itty* that would behave like
"normal" ttys, much like ucom...
- Hubert
--
NetBSD - because Unix isn't just #include <linux.h>, i386, ILP32, ELF, ...!
Lennart Augustsson
> On Thu, 20 Jul 2000, Lennart Augustsson wrote:
> > One way to handle serial ports is to do it all in user-land code, an alternative
> > is to use a different line discipline for IrDA and access it through /dev/irdaNN.
> > Either way, the problems above is present.
>
> Will there still be a /dev-node then that I can hand to
> pppd/kpppd/kermit/whatever to do the modem control etc., or
> will interfacing with a different method be required?
> It would be nice if there was some /dev/itty* that would behave like
> "normal" ttys, much like ucom...
For now, there will be a pty. That should be enough for most programs.
If we decide to migrate the IrDA stack into the kernel we could make /dev/itty.
--
-- Lennart
Chuck McManis
>For now, there will be a pty. That should be enough for most programs.
>If we decide to migrate the IrDA stack into the kernel we could make
>/dev/itty.
And bluetooth support could be, .... wait for it ... /dev/wtty
:-)
--Chuck
Ignatios Souvatzis
> On Thu, Jul 20, 2000 at 11:41:23PM +0200, Ignatios Souvatzis wrote:
>
> > On Thu, Jul 20, 2000 at 01:53:49PM -0700, Jason R Thorpe wrote:
> > > that?
> >
>
> Yuck, copying packets across protection boundaries! :-)
Maybe we really need something like streams or netgraph, so that we can
dynamically fuse translators inside the kernel....
-is
Jason R Thorpe
> Maybe we really need something like streams or netgraph, so that we can
> dynamically fuse translators inside the kernel....
Personally, I'd say streams, because that would be useful for the
kbd/ms thing on serial ports, too.