Andrew Sutton wrote :
>
> finally a non-configuration question ;)
Ah... Fun...
> jean this is mainly directed to you,
> but anybody else with input is welcome to respond.
Me ? Why ?
> background: as some of you long time subscribers may know/remember, my
> company is working on a project to implement an IEEE standard for medical
> device communications (IEEE 1073/ISO 11073) that mandates IrDA as the primary
> transport. however, the discovery/connection stuff in af_irda is a little
> tedious to make work optimally in cases where devices can be plugged in and
> unplugged in rapid succession. imagine waiting for a critical care device to
> sync and connect while you're in the emergency room quickly bleeding to
> death...
>
> so, in short we're looking for a way to make the discovery stuff in the irda
> kernel highly reactive to discovery and expiry events. jean, we had a brief
> conversation about this some time ago, but i don't know if anything came of
> it.
I gave you a few pointers, and nothing more.
> as it is, we're using the WAITDEVICE sockopt to determine when devices are
> connected and disconnected. this doesn't work quite so well because of issues
> with the timeout and expiry time. in order to unplug and replug a device
> we're having to unplug it, wait for the expiration timer and then replug it.
> this can sort of be fixed by testing for active connections on a discovered
> device but doesn't completely eliminate the problem.
The only way to make the discovery/expiration quicker is to
decrease the period of discovery. You can't discover/expire until you
do the next discovery, which is every 3s.
> after some analysis, we've come to the conclusion that we essentially need
> the equivilant of an event channel written into the af_irda layer. in other
> words, we want a blocking call that will return a single event - either
> discovery or expiry. unfortunately, this is kind of hard to implement in the
> sockets API for a AF that already has a protocol implementation.
Correct. What you want is to export the event through the
netlink socket API. For example, you could use a RTnetlink
event. That's what I've started to do for 802.11.
> the way i see it there would be two or three ways to accomplish this. first,
> a sockopt call could be added that would implement this behavior (say,
> WAITEVENT). it would work like WAITDEVICE except that instead of simply
> indicating the existence of a device by returning it could return a discovery
> or expiry record indicating what just happened. this is probably the easiest
> solution.
Won't work : events will get lost while you process an
event. Don't do that.
> i believe that jean has already written some of the discovery stuff such that
> it works with select.
What works with select is the IrNET control channel.
If you preload (but don't use) the IrNET module on each
device, you could do select+read on /dev/irnet and get your
event. That would be the simplest solution. Just try it.
> i think this could possibly be expanded to include
> expiry events. this actually makes the solution a little more interesting
> because it can completely obliterate the semantics of a regular select()
> call. a simple solution would be to only allow discovery/expiry select()ion
> on sockets that are neither listen()ing or connect()ing. a read indication
> could mean that a device was discovered while an OOB/except indication could
> mean that a device has expired. the question now, is how to get the event
> from irda implementation. possible solutions include a getsockopt (say,
> GETEVENT) or (more interestingly) simply calling recv() or read() to return a
> record indicating which event occured.
getsockopt is not the way to go, you will loose events and
can't do a select (i.e. can't wait on multiple source of events). read
would imply creating a specific socket type.
> this leads to the third possiblity which is a little different, but not
> entirely a bad idea: discovery access could be coded as a completely
> different AF (AF_IRDISCOVERY or something like that). that would enable a
> much broader range of semantics to be invented for controlling the discovery
> protocol in IrDA - although it "may" be a little more complicated ;)
I would rather use a netlink socket, but that's personal
choice. I feel it would be less complex.
> now, i realize there's probably going to be some issues involving new
> interfaces at this stage in kernel development,
2.5.X is wide open for that.
> but this i think this is
> pretty important and should probably be addressed. my company is committed to
> implementing the changes required for an event driven discovery API, but
> we're mainly looking for feedback at this point. so, if anybody (jean?) has
> any thoughts or ideas, i'd love to hear them.
I've started to add Wireless Events for 802.11 card. It is
just a specific sub-event on the RTnetlink channel. The patch is
pretty simple and included on my web page :
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html#newapi
It would be pretty simple to use the same mechanism to add
some IrDA events for discovery and expiry. You could even make then
generic by transporting a bunch of struct sockaddr in the event. And
you could also add other types of interesting events, such as socket
creation and destruction.
Also, please take a *deep* look of what I did in IrNET. I
spend time to create the right types of events that you need over IrDA
with the right parameters (I went through several iterations).
> sorry this was so long :)
> thanks in advance,
>
> andrew sutton
Have fun...
Jean
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
