Hi, I am maintaining a driver outside of the kernel. I'm more than happy to keep abreast of any changes via this forum and implement any changes needed. On Point 3) I would be happy to see this go, for us it will be 1 WPAN <-> 1 PHY. Point 4) Yielding the processor in the driver doesn't feel right to me, it would surely reek havoc with any implementation of Beacon enabled PANs. ie MAC layer wants to send a beacon only for the driver to sleep for a bit. Maybe the spec caters for this, I haven't gone into it in that sort of detail yet.
On a different sleeping point what about sensors applications that want to duty cycle for long periods to conserve battery, is this supported in the current architecture? I don't see anything in ieee802154_ops unless we stop and then restart the driver. Regards, Martin. On 07/03/14 12:16, Phoebe Buckheister wrote: > Hi, > > the 802.15.4/6LoWPAN stack on Linux is pretty usable as it is now, much > due to the recent 6lowpan fixes by Alex. We can drive different radio > chips on different frequencies, IPv6 works well and we interoperate > just fine with RFC compliant stacks like the one implemented in Contiki. > > There are, however, also a number of sore points, which I want to > outline in this message and for which I want to propose possible > solutions. These sore points range anywhere from minor annoyances to > what I view as major integrity problems. I'll list what comes to my > mind here, in no particular order. If you have any idea how to fix > something, if you have something to add to the list or merely want to > tell me where and why I am mistaken, please do so. > > 1) header handling in the stack > > We currently have three points in the stack that parse or create > 802.15.4 headers, where two of those are already duplicated code - in > the same source file no less. Header handling for mac802154 is > cumbersome, and for upper layers entirely impossible without > duplicating more code at the moment. I have a patch that attempts to > rectify this by adding structs for the 802.15.4 header and its > components, but that was shot down by davem due to some endianness > issues. I am reworking the patch to fix all of this and will resend it > soon, but it doesn't end with that. > > 2) endianness in the stack > > In fact, that patch was consistent with how the mac802154 stack > currently handles endianness - which is, pretty much, not at all. For > example we have __le16 fields that the PAN ID of a given netdevice, > which is filled with data in host byte order and only happens to work > out because it's written to the header with explicit mask-shift > operations. Short addresses for nodes are given in host byte order, > extended addresses are however always held in big endian 8-byte arrays. > We really never use network byte order on purpose, and inside of the > stack we should really change that. Ideally we'd also change it in the > userspace API if we ever got the chance to do that, because > AF_IEEE802154 is the *only* protocol i know that uses all byte orders > in it's sockaddr struct *except* network byte order. > > 3) the mac802154_priv slave list > > This is one of the biggest problems I think the current stack has. For > HardMAC, every netdevice corresponds to one specific WPAN (made up of > PAN ID, channel, and page) and it is pretty much guaranteed that > multiple HardMAC netdevs will always function as intended, even if they > are backed by the same piece of hardware. > > SoftMAC, on the other hand, takes a single PHY chip and adds an > *arbitrary* number of specific WPANs on top of that PHY. No real > hardware can support an arbitrary number of specific WPANs, and no chip > I have yet come across can even support more than one. As far as I've > been told and was able to reconstruct from documentation and standards > documents, this was implemented to allow for ZigBee frequency agility, > but that was never implemented. What we have, though, is a means for > unprivileged users that can run socket(), write() and ip(8) to > effectively DoS a node that uses this feature. > > Here's why: if somebody configures the stack with one PHY and two > specific WPANs on that PHY, an packet sent through one of those > specific WPAN netdevs will activate that specific WPAN and deactivate > all others on that PHY. This only holds when the specific WPANs differ > in channel or page, since we do not reconfigure the PHY addresses or > address filters on on the switch, which will most certainly yield > wildly incorrect behaviour if anybody were to ever use multiple > specific WPANs per PHY. > > I thus propose to remove this feature entirely and instead have a 1:1 > correspondence between PHYs and netdevs. If a driver can support > multiple specific WPANs per chip, it can register multiple PHYs. If > anybody actually needs to reconfigure the device to a different > specific WPAN, we already have an interface for that: the netlink API. > The netlink API also has the benefit that it does not impose arbitrary > delays before the switch, as switching by sending a packet does when > reordering/shaping Qdiscs are configured on the WPAN. > > If we were to remove the slave list, the entire netlink API specific to > PHYs and adding/removing slaves would have to go. Listing PHYs would no > longer be necessary, instead we'd need an API to query PHY/MAC > parameters by netdev name. What is currently SET_PHYPARAMS (and my > fault) would also have to be split into commands that set PHY and MAC > params for consistency. > > I propose a flag day to remove this feature entirely, as it will break > userspace, but it will do so to provide much better service, > semantically correct netdevs and it will remove the DoS path for > unprivileged users. And if we do that, we might as well think about > whether or not we should also change endianness of network-facing > fields exposed to userspace for consistency with all other protocols > implemented in Linux. > > 4) our *drivers* are expected to *sleep* > > This is just wrong. Our RX/TX path invokes the scheduler at least once > for every packet on the assumption that drivers might sleep, which may > entail arbitrary delays even after the Qdiscs of the system have run. > Especially when somebody wanted to use latency sensitive Qdiscs, this > is a disaster, but also for general system throughput once you have a > certain number of packets going through your node. > > I think this should also be reworked completely. Network packet > reception/transmission is inherently asynchronous, and the current > stack goes out of its way to make it a synchronous matter. > Interestingly, once a driver has received a packet, most if not all of > the RX path might actually be softirq-safe as it is now, without the > workqueue deferral. We don't fundamentally need the RX workqueue, and > the TX workqueue could also be dropped if we gave a PHY driver a > function pointer to call once transmission is complete. That would also > simplify the stack quite a bit, not introduce unnecessary latencies, > and generally be an improvement on drivers that invoke the scheduler. > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > Linux-zigbee-devel mailing list > Linux-zigbee-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
