Skip to content

Conversation

zhuoshuguo
Copy link
Contributor

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.

/* PID of MAC thread */
kernel_pid_t pid;
/* NETDEV device used by MAC */
gnrc_netdev2_t* netdev;
Copy link
Member

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

Copy link
Contributor Author

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;
Copy link
Member

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?

@zhuoshuguo
Copy link
Contributor Author

updated.

@miri64
Copy link
Member

miri64 commented Oct 20, 2016

See zhuoshuguo#2

} gnrc_netdev2_t;

bool gnrc_netdev2_get_rx_started(gnrc_netdev2_t *dev)
Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

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"
Copy link
Member

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.

Copy link
Contributor Author

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
Copy link
Contributor Author

@zhuoshuguo zhuoshuguo Oct 28, 2016

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)

Copy link
Member

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.
Copy link
Contributor Author

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

Copy link
Member

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?

Copy link
Member

@daniel-k daniel-k Oct 28, 2016

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.

Copy link
Member

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same goes here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here, too.

@zhuoshuguo
Copy link
Contributor Author

@miri64 with your agreement on the function description, updated. Sorry for the late reply. :-)

@miri64 miri64 added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Oct 31, 2016
@miri64
Copy link
Member

miri64 commented Oct 31, 2016

I'm fine with this PR now as is. Maybe we can get this into the release. Please squash.

@miri64 miri64 added this to the Release 2016.10 milestone Oct 31, 2016
@zhuoshuguo
Copy link
Contributor Author

Squashed.

extern "C" {
#endif

typedef enum {
Copy link
Member

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).

@miri64
Copy link
Member

miri64 commented Nov 1, 2016

Postponed due to feature freeze.

@miri64 miri64 modified the milestones: Release 2017.01, Release 2016.10 Nov 1, 2016
@zhuoshuguo
Copy link
Contributor Author

Updated, added documentation. @miri64 Sorry for the slow action.

@miri64 miri64 added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Nov 4, 2016
@zhuoshuguo
Copy link
Contributor Author

@miri64 Is this PR OK for merge now? :-)

Copy link
Member

@miri64 miri64 left a 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants