Hi Andrew,
On Mon, 12 Nov 2001, Andrew Sutton wrote: > > Btw, I'm wondering whether there would be some general need to provide > > access to the traffic on the physical layer without having an IrDA stack > > on top of the driver. Something like raw SIR byte stream. Sure, we have > > this available for all the systems which use irtty - but not for FIR-style > > drivers, IIRC. Would it make sense to define such an interface? It would > > be helpful for people using peer devices without any IrDA stack at all, so > > they can not even use Ultra sockets. I was asked this for the VLSI and it > > should be possible to do - options are either significant code duplication > > or adding a generic interface but for VLSI alone I doubt it's worth the > > effort. > > i think this would be a nice feature, but i think it would require something > more than a small change in the kernel. the way i'm reading this is that you > want to have an api that allows you to access stats from low level > communication interfaces without necessarily having a stack attached to that > interface, correct? Right. I'm thinking about an entity (tentative name: ir-marshall, the term irmanager might lead to confusion with a now-obsolete userland tool) which manages connectivity between ir service providers (drivers) and requestors (present in-kernel irda-stack or userland interfaces like a tty or access to any OSI layer 2 networking). I believe this could be done such a way this ir-marshall would behave like existing Linux-IrDA drivers - so there would be little or even no change to be made on the stack. Existing drivers would continue to work directly with the stack, but would require some changes, if they should provide the new features for ir-marshall. The new interface between ir-marshall and new-style drivers would be independent form IrDA-specific dependencies. Drivers just register there instead of directly calling register_netdev() and indicate to the ir-marshall which kind of service they could provide. Well, this is just an idea which came into my head recently because there was some request to get access to the SIR-bytestream without having neither the irda stack nor the frame wrapper in the middle. And there might be some general demand for something like this - at least there was already some serial-tty interface introduced for the USB dongles and if you think about new controllers like the TIR2000 it would be helpful when integrating their ASK-IR and TV-remote modes. In fact there is already some notion of such modes in net/irda/irda_device.c but almost unused - I think some serial dongles makes use of what is called "IRDA_RAW" mode there. > actually, i really think this might be the right way to go because it > provides a common underlying layer for the irda stack. Yes. I believe recent threads have shown we (almost) all agree we have a very good Linux-IrDA stack - Thanks again to you Dag, Jean and others. And we have a number of drivers which - despite some limitations - aren't that bad either. So why not making the driver independent from the stack and provide its capabilities to whoever it may useful for? The point is whether there are enough applications which would benefit or whether this would just add some bloat only on behalf of its own. > implementing this might actually be the first step to moving the irda stack > completely out of the kernel. if a generic irda interface were defined for > both sir and fir ports, the stack could move to user space and use the > interfaces provided by the sir/fir drivers to implement stack functionality. That's definetly true, although it's not the primary goal of my question. IIRC the Linux-IrDA stack just went the opposite direction from userland into the kernel. Personally, I believe we have a real good existing stack and I see no need to duplicate it in userland. But, if somebody wants to use another one in userspace - why not? In return this might even help to improve the drivers (due to both more developing power and installed base hopefully helping to get more vendor support) - so the in-kernel stack would profit from this as well. > hmm... interesting :) Anyway, this is definitely a 2.5 thing. And currently I'm too short in time to promise anything will happen - at least in the short term. I wonder whether we should just open a new thread to collect related issues. Martin _______________________________________________ Linux-IrDA mailing list - [EMAIL PROTECTED] http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
