{"action":"created","issue":{"url":"https://api.github.com/repos/RIOT-OS/RIOT/issues/5595","repository_url":"https://api.github.com/repos/RIOT-OS/RIOT","labels_url":"https://api.github.com/repos/RIOT-OS/RIOT/issues/5595/labels{/name}","comments_url":"https://api.github.com/repos/RIOT-OS/RIOT/issues/5595/comments","events_url":"https://api.github.com/repos/RIOT-OS/RIOT/issues/5595/events","html_url":"https://github.com/RIOT-OS/RIOT/issues/5595","id":163689219,"number":5595,"title":"MAC layer in complex L2 protocols (Request for comments)","user":{"login":"jia200x","id":1260616,"avatar_url":"https://avatars.githubusercontent.com/u/1260616?v=3","gravatar_id":"","url":"https://api.github.com/users/jia200x","html_url":"https://github.com/jia200x","followers_url":"https://api.github.com/users/jia200x/followers","following_url":"https://api.github.com/users/jia200x/following{/other_user}","gists_url":"https://api.github.com/users/jia200x/gists{/gist_id}","starred_url":"https://api.github.com/users/jia200x/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jia200x/subscriptions","organizations_url":"https://api.github.com/users/jia200x/orgs","repos_url":"https://api.github.com/users/jia200x/repos","events_url":"https://api.github.com/users/jia200x/events{/privacy}","received_events_url":"https://api.github.com/users/jia200x/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/RIOT-OS/RIOT/labels/GNRC","name":"GNRC","color":"d4c5f9"},{"url":"https://api.github.com/repos/RIOT-OS/RIOT/labels/network","name":"network","color":"8f00cc"},{"url":"https://api.github.com/repos/RIOT-OS/RIOT/labels/Request%20for%20Comments","name":"Request for Comments","color":"23F823"}],"state":"open","locked":false,"assignee":{"login":"miri64","id":675644,"avatar_url":"https://avatars.githubusercontent.com/u/675644?v=3","gravatar_id":"","url":"https://api.github.com/users/miri64","html_url":"https://github.com/miri64","followers_url":"https://api.github.com/users/miri64/followers","following_url":"https://api.github.com/users/miri64/following{/other_user}","gists_url":"https://api.github.com/users/miri64/gists{/gist_id}","starred_url":"https://api.github.com/users/miri64/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/miri64/subscriptions","organizations_url":"https://api.github.com/users/miri64/orgs","repos_url":"https://api.github.com/users/miri64/repos","events_url":"https://api.github.com/users/miri64/events{/privacy}","received_events_url":"https://api.github.com/users/miri64/received_events","type":"User","site_admin":false},"assignees":[{"login":"miri64","id":675644,"avatar_url":"https://avatars.githubusercontent.com/u/675644?v=3","gravatar_id":"","url":"https://api.github.com/users/miri64","html_url":"https://github.com/miri64","followers_url":"https://api.github.com/users/miri64/followers","following_url":"https://api.github.com/users/miri64/following{/other_user}","gists_url":"https://api.github.com/users/miri64/gists{/gist_id}","starred_url":"https://api.github.com/users/miri64/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/miri64/subscriptions","organizations_url":"https://api.github.com/users/miri64/orgs","repos_url":"https://api.github.com/users/miri64/repos","events_url":"https://api.github.com/users/miri64/events{/privacy}","received_events_url":"https://api.github.com/users/miri64/received_events","type":"User","site_admin":false}],"milestone":null,"comments":2,"created_at":"2016-07-04T14:34:32Z","updated_at":"2016-07-04T16:07:54Z","closed_at":null,"body":"Hi all.\r\n\r\nWe were discussing with @kYc0o about the proper way to implement complex L2 protocols in RIOT.\r\nI have been working mainly with the L2 layer of RIOT while porting OpenThread, implementing PPP, etc. And sometimes I have had some problems trying to handle L2. \r\n\r\nFor example, PPP is a stack of protocols in L2 (LCP, Auth, NCP, etc). These subprotocols have to communicate each other via IPC msgs ([msg_send_to_self]) and have some timeouts (handled by [xtimer_set_msg] via IPC too). The driver and MAC layer are running in the same thread, but I couldn't find a clean way to extend gnrc_netdev2 to handle this kind of messages (they might go through NETDEV2_MSG_TYPE_EVENT, but in the end they go to the driver's isr which only receives a pointer to the driver itself [gnrc_netdev2 loop]).\r\n\r\nSo, I didn't use gnrc_netdev2 and made a small L2 layer that handles this (see [gnrc_ppp loop]).\r\n\r\nAlso, sometimes PPP requires to send specific command to the driver (dial up, reset, etc). I did the same structure as netdev2, but added some of these functions (see [pppdev_driver_t]). Also, I slightly modified the isr function (renamed to driver_ev that also has an extra argument for giving an event).\r\n\r\nI think would be nice to reuse the existing structures for not reinventing the wheel, so:\r\n\r\n\r\n- What do you think is the right way to handle these kind of L2 protocols in RIOT trying to maximize code reuse?\r\n- Is there something like a generic MAC layer that can handle these kind of L2 protocols? If not, does it make sense to have one?\r\n- How should actions from L2 to the driver be treated? (like netdev2's get and set, but for actions like hang out, dial up, etc).\r\n\r\n\r\nBest regards\r\n \r\n\r\n[xtimer_set_msg]: http://riot-os.org/api/group__sys__xtimer.html#ga1f882b73e60fa5854b4e5e843dcff5f6\r\n[msg_send_to_self]: http://riot-os.org/api/group__core__msg.html#ga8711110548c90fe5ca82215e89bb83dd\r\n[gnrc_netdev2 loop]: https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/link_layer/netdev2/gnrc_netdev2.c#L141\r\n[gnrc_ppp loop]: https://github.com/RIOT-OS/RIOT/pull/5470/files#diff-ed6a8c8bc3c7ce6f932da3bf4ab7e173R338\r\n[pppdev_driver_t]: https://github.com/RIOT-OS/RIOT/pull/5470/files#diff-f2ab1d3d0bb4214f88e8a2ad9492d52dR108"},"comment":{"url":"https://api.github.com/repos/RIOT-OS/RIOT/issues/comments/230320577","html_url":"https://github.com/RIOT-OS/RIOT/issues/5595#issuecomment-230320577","issue_url":"https://api.github.com/repos/RIOT-OS/RIOT/issues/5595","id":230320577,"user":{"login":"jia200x","id":1260616,"avatar_url":"https://avatars.githubusercontent.com/u/1260616?v=3","gravatar_id":"","url":"https://api.github.com/users/jia200x","html_url":"https://github.com/jia200x","followers_url":"https://api.github.com/users/jia200x/followers","following_url":"https://api.github.com/users/jia200x/following{/other_user}","gists_url":"https://api.github.com/users/jia200x/gists{/gist_id}","starred_url":"https://api.github.com/users/jia200x/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jia200x/subscriptions","organizations_url":"https://api.github.com/users/jia200x/orgs","repos_url":"https://api.github.com/users/jia200x/repos","events_url":"https://api.github.com/users/jia200x/events{/privacy}","received_events_url":"https://api.github.com/users/jia200x/received_events","type":"User","site_admin":false},"created_at":"2016-07-04T16:07:54Z","updated_at":"2016-07-04T16:07:54Z","body":"Hi Martine.\r\n\r\n\r\n> I don't quite understand why you didn't implement PPP on top of netdev2, like other MAC protocols would also be implemented\r\n\r\nI did this for 2 reasons:\r\n\r\n1. Handling of actions. \r\n2. Passing arguments from ISR to the isr handler (AT command finished, data received, AT timeout received, etc). \r\n\r\nAs you said, would be possible to handle 1 as \"set\" options (just as brainstorming, does it make sense to have in a future release something like an \"action\" hook?). The second reason has some solutions too (e.g state variables).\r\n\r\nActually if these 2 things are solved, it's very easy to adapt the pppdev to netdev2 (almost straightforward, as they do almost the same).\r\n\r\n\r\n>  I don't quite understand what the problem with NETDEV2_MSG_TYPE_EVENT here is? That's for interaction with the actual device, not the MAC layer... Maybe I'm missing (and missed in the past) something, so please help me see.\r\n\r\nPlease feel free to comment/discuss about this part:\r\n\r\nUnder the supposition of the same thread for MAC and driver (so, same msg loop), there are messages from device/driver and from the L2. \r\nFrom the device/driver part, I'm auto-sending messages like AT command finished, data received, etc (this suits ok with NETDEV2_MSG_TYPE_EVENT). \r\n\r\nFrom L2 part, I have defined some structs representing subprotocols that are stacked. There are some messages between them (e.g LCP telling NCP that the link is ready, xtimer msg triggered by NCP indicating a timeout of network protocol negotiation, etc). Basically these functions are abstracted as a MSG_TYPE_EVENT and an uint32_t that contains target and event. \r\n\r\nIn the beginning I wanted to use gnrc_netdev2 for this, but couldn't find a way to pass these kind of events. How could I reuse the same gnrc_netdev2 loop to make this possible? If this is solved, then there's no need to have a different event loop.\r\n\r\nIf something was not clear, don't hesitate to ask again.\r\n\r\nCheers!\r\n\r\n"}}
{"actor":{"display_login":"jia200x"}}