On 05/03/12 11:21, Felix Varghese wrote: > On 5 March 2012 00:31, Dmitry Eremin-Solenikov <dbarysh...@gmail.com> wrote: >> Hello, >> >> On Sun, Mar 4, 2012 at 9:05 PM, Felix Varghese <felixv1...@gmail.com> wrote: >>> This is the terminology we tried to follow consistently >>> in the code. If we are aiming for IEEE compliance and >>> interoperability, we would need to implement a get and set for each >>> and every one of these attributes (although indeed the terminology >>> wouldn't matter!). So, even if these attributes weren't actually got >>> or set anywhere in the code (which they would be, as an when new >>> features are implemented), their implementation is a significant step >>> towards building an proper 802.15.4 implementation. >> >> Yes and no. First, do you plan to have standard compatibility on the >> "procedure" level of things - I mean implementing all procedures as >> defined by standard? They don't always fit the Linux model. E.g. >> there are probably better ways to implement passing of scan results >> to userspace, comparing to the standard text. I'm really not sure >> that implementing PHY PIB as get/set is a "Goot Thing". Etc. > > I agree that it doesn't seem good to expose such low level > functionality outside the kernel, but I don't think we have a choice > on that if we expect our stack to be usable for Zigbee or RF4CE or any > other network layer that expects and "IEEE 802.15.4 MAC". Both expect > all PIBs related to non-beacon enabled MAC to be exposed, including > channel and channel page (RF4CE stack can hop channels at will). If we > do not implement it as the spec recommends, sooner or later, somebody > who is porting a network layer on top of MAC might be surprised to > realize that he is missing something important which he has no means > of getting.
802.15.4e also adds optional channel hopping. I do not remember exact timing requirements. Would it be possible to implement channel hopping without hardware (radio) help on a non-RT-enabled Linux? And even if it is possible, I think channel hopping should be implemented in the lowest stack layers. So one will then set channel hopping parameters directly, not hop the channel each time manually. > > For the same reason, it would be ideal if all other MLME primitives > recommended by the standard are implemented (via NL or some other > interface) with minimal variations. Most existing 802.15.4 MAC > implementations on the smaller devices follow this interface > consistently for at least MLME and MCPS. Of course, we are free to > modify the MAC-to-PHY interface in any way we want because it is all > internal to the kernel. And in our case, MCPS data request and > indication should obviously use AF_IEEE802154 socket write() and > read() respectively. Apart from that, we would like to suggest that we > try to go by the standard wherever possible, except where it would > stand in our way, in which case we should undoubtedly take a different > route! This will ensure that our stack is usable by anyone who wants > to implement any protocol over an "IEEE 802.15.4 MAC". It has some established "best practices" and some deficiencies towards standards implementation Well... For small devices it might be a good idea to follow standard word by word. For Linux it is not so good idea. Linux is multi-process, multi-interface and multi-user environment. E.g. the DATA calls are already implemented not following the interface described in the standard. PURGE call will have to be implemented in some not-so-standard-following way. I don't know yet, how it should be implemented. Maybe you can propose something. Scanning, COMM-STATUS and several other topics do not fit directly into my thought of Linux. >>> The PIB also forms >>> the backbone over which the rest of the features would fit in. The MAC >>> primitives, when implemented, will use these attributes heavily. >> >> Yes, it is true. But strictly speaking PIB is not the most important >> part of the standard to implement. It is true that we did not implement >> GET/SET/RESET commands due to various reasons ranging from >> problems with designing good interface to PIB. I'm not sure that >> NetLink is well suited for such task. Could you please consult with >> cfg80211 subsystem to check how they implemented access to >> their information base variables? > > Okay. From our perspective, though, the existing netlink-based > interface seemed ideal for PIB implementation (and all other MLME > primitives too, for that matter) because it would be easily and > consistently accessible using very similar code from both userspace > (for perhaps a Zigbee, Zigbee pro or RF4CE stack) and kernel space > (for 6lowpan and friends). Yes, it was done so exactly on this purpose. I'm just unsure how PIB should fit into NetLink interface. -- With best wishes Dmitry ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
