-
Notifications
You must be signed in to change notification settings - Fork 2.1k
gnrc: create the basic "gnrc_mac" type for providing common MAC functionalities #5941
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
298ee7a
to
a55ec0a
Compare
/* PID of MAC thread */ | ||
kernel_pid_t pid; | ||
/* NETDEV device used by MAC */ | ||
gnrc_netdev2_t* netdev; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least these to above are already provided by gnrc_netdev2_t
, which should be used to implement MAC anyways by providing a send
and recv
implementation in my opinion. I also think that was how @kaspar030 intended it. Feel free to amend to that struct, but I think it could be beneficial to #ifdef MODULE_GNRC_MAC
them out
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, this is inherited and extracted from the original Lw-MAC module, and I didn't changed too much the original design.
But, anyway, that is a good idea to put some new MAC operations into gnrc_netdev2_t, I will see what I can do. :-)
kernel_pid_t pid; | ||
/* NETDEV device used by MAC */ | ||
gnrc_netdev2_t* netdev; | ||
const netdev2_driver_t* netdev2_driver; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is incorporated in gnrc_mac_t::netdev
. Why is this here?
a55ec0a
to
ba9cb41
Compare
updated. |
See zhuoshuguo#2 |
} gnrc_netdev2_t; | ||
|
||
bool gnrc_netdev2_get_rx_started(gnrc_netdev2_t *dev) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@miri64 should we static inline
this function and others below here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooops, that was my code right? Yes, that would be better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that was originally come from your code.
I will adapt them. :-)
#include "kernel_types.h" | ||
#include "net/netdev2.h" | ||
#include "net/gnrc.h" | ||
#include "net/gnrc/mac.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be changed to net/gnrc/mac/types.h
, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah! Thanks.
} gnrc_netdev2_t; | ||
|
||
#ifdef MODULE_GNRC_MAC |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@miri64 I also #ifdef MODULE_GNRC_MAC
the gnrc_mac
related functions, is that OK? (I think I also have to do it, otherwise the compile will not pass due to mac_info
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, helps to throw compiler errors if you use the functions if you not supposed to.
* @brief set the rx_started state of the device | ||
* | ||
* This function is intended to be called only in the _event_cb function of | ||
* the netdev2 device. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@miri64 could you help check the correctness of the description here? That is also how I understand the usage of these functions. Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uhmm.. I don't know about the usage restrictions of this function... as is it can be called from anywhere in the MAC thread (but is restricted to that thread). @daniel-k was the rx_started boolean from your implementation supposed to only be called in the event callback?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@daniel-k was the rx_started boolean from your implementation supposed to only be called in the event callback?
In my implementation rx_started
was part of the global LwMAC state struct. I didn't follow the refactoring to that detail, so I don't know who introduced gnrc_netdev2_set_rx_started()
, sorry :/
But this function might be dangerous in general. If I remember correctly, _event_cb()
can be called in interrupt context as well as in thread context, but it is definetly not thread-safe (docs should reflect that IMHO). Furthermore, manipulating the rx_started information from outside the MAC layer will also cause malfunction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my implementation rx_started was part of the global LwMAC state struct. I didn't follow the refactoring to that detail, so I don't know who introduced gnrc_netdev2_set_rx_started(), sorry :/
That was me, but the functionality is the same as the rx_started
variable, just a little bit more memory friendly ;-)
But this function might be dangerous in general. If I remember correctly, _event_cb() can be called in interrupt context as well as in thread context, but it is definetly not thread-safe (docs should reflect that IMHO). Furthermore, manipulating the rx_started information from outside the MAC layer will also cause malfunction.
Okay then let's restrict the usage to the event callback. @zhuoshuguo please replace "_event_cb
of the netdev2 device" with "netdev2_t::event_callback()
" this way it gets properly referenced by the doc parser.
* @brief set the transmission feedback of the device | ||
* | ||
* This function is intended to be called only in the _event_cb function of | ||
* the netdev2 device. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same goes here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here, too.
@miri64 with your agreement on the function description, updated. Sorry for the late reply. :-) |
I'm fine with this PR now as is. Maybe we can get this into the release. Please squash. |
fb42331
to
ed7deef
Compare
Squashed. |
extern "C" { | ||
#endif | ||
|
||
typedef enum { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This type (and its members) still requires documentation (please squash that immediately).
Postponed due to feature freeze. |
ed7deef
to
d8082c9
Compare
Updated, added documentation. @miri64 Sorry for the slow action. |
d8082c9
to
6f39d8c
Compare
@miri64 Is this PR OK for merge now? :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, ACK and go when Murdock is happy.
The goal is to finally create/provide a "gnrc_mac" module which will provide common parameters and functionalities for MAC developers.
This PR first introduces a basic "gnrc_mac_t" type which will be improved by latter PRs to contain more key parameters and functionalities that most MAC protocols will use/adopt, to increase code reuse for MAC developers.