Re: [riot-devel] On the State of RIOT's IEEE 802.15.4 Support
Hi Joakim, Thanks for sharing your point of view. Personally I think it complicates MAC protocol implementations when they somehow have to accommodate 802.15.4 functionality and deal with e.g. starting and maintaining the PAN and I'd expect we will have to use more #ifdefs. In my opinion runtime functionality as described in 6.3 and following of the standard also doesn't need to run with the same priority as the actual MAC protocol. Your approach would however benefit upper layers I think as the interface wouldn't have to change. In the end I'm fine with whatever works and covers our requirements. Best, Thomas On 20 Sep 2017, at 1:11 PDT(-0700), Joakim Nohlgård wrote: Hi, I have recently been digging around the gnrc_netdev code as well. I think that adding support for other frame types and logic for sending these frames will definitely become a mess if the 802.15.4 code is not decoupled from the netdev code. Especially if someone would like to add advanced features like 802.15.4e TSCH, which requires version 2 framing and a number of special MAC header fields. I don't think the 802.15.4 layer needs to be in its own thread though, it should be enough to separate the framing functionality from the send/recv code and let the MAC layer handle it internally, and keep the 802.15.4 layer in the same thread as the netdev driver, like gnrc_netdev does today. /Joakim On Wed, Sep 20, 2017 at 12:16 AM, Thomas Eichingerwrote: Hi Oleg! On 19 Sep 2017, at 13:24 PDT(-0700), Oleg Hahm wrote: On Sun, Sep 17, 2017 at 02:37:39PM -0700, Thomas Eichinger wrote: A while ago I worked on adding support for MAC commands and procedures the standard describes like channel scanning and automatic association of a device with a coordinator. Personally I think those are nifty features to provide, the reality check the last two days showed though that it'd need some non-trivial refactoring of the existing 15.4 code to not end up in #ifdef hell. Can you elaborate a little bit on this part? I would assume that being compatible with other 802.15.4 implementations requires run-time flexibility, i.e., react properly to optional features implemented by other 802.15.4 devices. Or were you proposing to have a minimal non-standard-compliant version _and_ standard-compliant version intermingled, sharing commmon code through preprocessor directives? Admittedly the "#ifdef hell" was a bit polemic and I didn't intend to propose offering a non-standard-compliant version. ;) Right now RIOT is very much streamlined to send and receive 802.15.4 data and ACK frames. The nontrivial refactoring I referred to would have to break this. On the receiving side I see the possibility to introduce an other nettype like GNRC_NETTYPE_802154 set by the corresponding frame type and the actual runtime logic would basically be in parallel of sixlowpan threads, hierarchically. (changing channels and hardware addresses, actively/passively scanning for coordinators...) That'd be at least my approach. On the sending side, however, the 15.4 header currently gets crafted in the netdev code and set to data frames. We'd have to take that out and let the upper layers define the frame type, or at least overwrite it. There will be more flags or header fields that will have to get configurable. Do others see a better approach? So, instead of having a minimal non-standard-compliant version I'd rather progress to a minimal standard-compliant version with the inevitable increase in code size. From there we can take it how far we want and make it configurable i.e. supporting IEs and use 802.15.9 to support key management etc. The sky is the limit. (Or as a German'd say "With sauce and spicy!") Does this somehow answer your question? Let me know if I missed it. Best, Thomas p.s.: Writing this it seems easier to do actually. Good we talked about it. :) ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] gnrc: MAC layer selection
Hi Joakim, Hi Shuguo, First of all: We know of this problem and I try to come up with a solution for this for a long time, so thanks for picking this up. A step into that direction (but not the final solution) was the refactoring of GNRC's interface layer (aka gnrc_netif2, see [1], should also simplify implementing new MAC-layers a lot ;-)). 2017-09-20 10:38 GMT+02:00 Shuguo Zhuo: > Hi, Joakim, > > This is a very good topic which also confuses me (with also my GoMacH MAC > implementation queued up in pipe). > > > One possible solution is to add a function pointer member to the > > `at86rf2xx_params_t` (and similar parameter structs for the other > > netdev drivers) for initializing the MAC layer, and let the user > > select the MAC layer there. > > This sounds like a good solution to me. > Waiting for responses from more experienced RIOT developers. ;-) > I see some problems with this for several reasons: a) This seems too device-specific for me. Can we maybe find a looser coupling. First thing coming to mind is a (void *, MAC_init_function)-tuple, where `void *` is an arbitrary params struct (this solution isn't perfect either because it requires some searching). b) Device configuration. That's a problem with our config in general. Say you have several devices the same type on a board (e.g. two at86rf233). If you want to change the config (i.e. switch MAC layer) for one device of that type you need to reconfigure *all* devices of that type, since they are in a static array. That sucks. c) We need to ensure that this solution isn't GNRC-specific. lwIP has a similar mechanism (different init functions for different MAC layers), but there abstraction only starts at the interface layer, so a user (or in our case our auto-init system) needs to know which device they want to use for which MAC layer (sounds familiar?) d) Function pointers. While I personally have no problem with function pointers and quite happily use them to achieve better modularity (see [1] ;-)), I know there are community members that don't think using too many function pointers is a good idea and make the code more complicated. Best Regards, Martine [1] https://github.com/RIOT-OS/RIOT/pull/7370 > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] On the State of RIOT's IEEE 802.15.4 Support
On Wed, Sep 20, 2017 at 11:32 AM, Kaspar Schleiserwrote: > Hi Joakim, > > On 09/20/2017 10:11 AM, Joakim Nohlgård wrote: >> I have recently been digging around the gnrc_netdev code as well. I >> think that adding support for other frame types and logic for sending >> these frames will definitely become a mess if the 802.15.4 code is not >> decoupled from the netdev code. > > Could you elaborate why? We should aim to get as much as possible > gnrc-independent code. I don't have an opinion on whether to depend on gnrc or not, but the current send and recv implementation in gnrc_netdev_ieee802154 acts as a wrapper for the real device driver send/recv functions, so the MAC layer calls the wrapper function which generates the frame header before passing on to the device driver. What I meant was that this header generation/parsing should be its own separate function that the MAC layer explicitly calls, instead of implicitly as a middle layer between the MAC and the network device driver. All of the header generation code is inside gnrc_netdev_ieee802154.c right now. That code is going to be a mess if more frame types are added, or different frame versions and header options should be supported. https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/link_layer/netdev/gnrc_netdev_ieee802154.c#L154 /Joakim ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] On the State of RIOT's IEEE 802.15.4 Support
Hi Joakim, On 09/20/2017 10:11 AM, Joakim Nohlgård wrote: > I have recently been digging around the gnrc_netdev code as well. I > think that adding support for other frame types and logic for sending > these frames will definitely become a mess if the 802.15.4 code is not > decoupled from the netdev code. Could you elaborate why? We should aim to get as much as possible gnrc-independent code. Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] gnrc: MAC layer selection
Hi, Joakim, This is a very good topic which also confuses me (with also my GoMacH MAC implementation queued up in pipe). > One possible solution is to add a function pointer member to the > `at86rf2xx_params_t` (and similar parameter structs for the other > netdev drivers) for initializing the MAC layer, and let the user > select the MAC layer there. This sounds like a good solution to me. Waiting for responses from more experienced RIOT developers. ;-) Bests, Shuguo - 原始邮件 - > 发件人: "Joakim Nohlgård"> 收件人: "RIOT OS kernel developers" > 发送时间: 星期三, 2017年 9 月 20日 上午 9:56:19 > 主题: [riot-devel] gnrc: MAC layer selection > > Dear developers, > Currently there are two different MAC layers for gnrc in the master > branch: basic gnrc_netdev, and gnrc_lwmac. gnrc_netdev is basically a > no-op MAC layer, only passes packets between the netdev driver and the > upper layers, while LWMAC is a duty cycling MAC implementation which > manages a schedule for the radio, including sleep. > > Which layer is used is selected by which init function is called > during boot, if gnrc_lwmac_init is called, then the device will run > LWMAC, or if gnrc_netdev_init is called, then the device will use > gnrc_netdev. auto_init has an `#ifdef` block checking for > `MODULE_GNRC_LWMAC` and uses that to select which init function is > called, but this is only implemented for the at86rf2xx driver, any > other drivers will need to have similar changes to their auto_init > functions as well. > > This current model is not going to scale well when new devices are > added and new MAC layers are implemented. All MAC layer > implementations will need to touch all netif auto_init > implementations. > > I am asking for ideas on how to make this more modular and less #ifdeffy. > > One possible solution is to add a function pointer member to the > `at86rf2xx_params_t` (and similar parameter structs for the other > netdev drivers) for initializing the MAC layer, and let the user > select the MAC layer there. > By default, we can use a macro GNRC_DEFAULT_INIT or similar to choose > the default MAC layer depending on the module selection. This would > behave like it is today for LWMAC, but the #ifdef hell would be kept > in a common header file, like gnrc_mac_default.h or something. > > What are your thoughts on this? > > I have a ContikiMAC MAC layer implementation queued up in the pipe for > inclusion in master and it will only make this situation worse if we > don't alter the current model. > > Best regards, > Joakim Nohlgård > Eistec AB > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] gnrc: MAC layer selection
Dear developers, Currently there are two different MAC layers for gnrc in the master branch: basic gnrc_netdev, and gnrc_lwmac. gnrc_netdev is basically a no-op MAC layer, only passes packets between the netdev driver and the upper layers, while LWMAC is a duty cycling MAC implementation which manages a schedule for the radio, including sleep. Which layer is used is selected by which init function is called during boot, if gnrc_lwmac_init is called, then the device will run LWMAC, or if gnrc_netdev_init is called, then the device will use gnrc_netdev. auto_init has an `#ifdef` block checking for `MODULE_GNRC_LWMAC` and uses that to select which init function is called, but this is only implemented for the at86rf2xx driver, any other drivers will need to have similar changes to their auto_init functions as well. This current model is not going to scale well when new devices are added and new MAC layers are implemented. All MAC layer implementations will need to touch all netif auto_init implementations. I am asking for ideas on how to make this more modular and less #ifdeffy. One possible solution is to add a function pointer member to the `at86rf2xx_params_t` (and similar parameter structs for the other netdev drivers) for initializing the MAC layer, and let the user select the MAC layer there. By default, we can use a macro GNRC_DEFAULT_INIT or similar to choose the default MAC layer depending on the module selection. This would behave like it is today for LWMAC, but the #ifdef hell would be kept in a common header file, like gnrc_mac_default.h or something. What are your thoughts on this? I have a ContikiMAC MAC layer implementation queued up in the pipe for inclusion in master and it will only make this situation worse if we don't alter the current model. Best regards, Joakim Nohlgård Eistec AB ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel