finally a non-configuration question ;) jean this is mainly directed to you, but anybody else with input is welcome to respond.
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. 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. 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. 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. i believe that jean has already written some of the discovery stuff such that it works with select. 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. 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 ;) now, i realize there's probably going to be some issues involving new interfaces at this stage in kernel development, 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. sorry this was so long :) thanks in advance, andrew sutton [EMAIL PROTECTED] _______________________________________________ Linux-IrDA mailing list - [EMAIL PROTECTED] http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
