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: >> On 3 March 2012 18:40, Dmitry Eremin-Solenikov <dbarysh...@gmail.com> wrote: >>> Summary on all the patchset below. >>> >>> Prajosh, Felix. Thanks for your work on IEEE 802.15.4 for Linux. Please >>> don't find my mails as discouraging or otherwise demoting your work. >>> There are some coding standards. There are some ideas behind code. There >>> is more than just blindly following standard text letter by letter. >> >> Firstly, thanks a lot for spending time to review these patches. We >> understand that we need put in a lot of work on them, and we are >> prepared to do that. > > :) > >> >>> First, your mixup of terms PIB and MIB leads to confusion. >> >> PIB, the way we meant it, stands for PAN Information Base, as defined >> in IEEE 802.15.4-2006. It is a collection of attributes, each of which >> has an attribute id and a corresponding value. It includes MAC PIB >> (stuff like short address, PAN ID, etc.) and PHY PIB (channel, channel >> page, etc.). > > Ah, ok. I'm sorry here. I've last read the standard about a year ago. Maybe > I mixed it up with some other standard. I had terms PIB and MIB in my mind. > >> 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. 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". > Regarding unused/unimplemented things. There is no point in > implementing just the "get/set" operations. They will be the dead code. > It might be used in future. And might not. Or they might require > a different implementation. Usually there is little point in implementing > such "features". I would really prefer to have code that uses those > values, rather than just list of values. Fair enough. We will try to add new attributes only as and when they are used in code. >> 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). Regards, Felix. ------------------------------------------------------------------------------ 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
