Skip to content
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

drivers/netdev_ieee802154: cleanup NETOPT_MAX_PACKET_SIZE #9864

Merged
merged 2 commits into from
Oct 16, 2018
Merged

drivers/netdev_ieee802154: cleanup NETOPT_MAX_PACKET_SIZE #9864

merged 2 commits into from
Oct 16, 2018

Conversation

SemjonWilke
Copy link
Member

This PR relieves code duplications in netdev interfaces and unifies them in the shared, generic ieee802154 netdev driver.
I focused on NETOPT_MAX_PACKET_SIZE by intent, if there are more obvious duplications, I will fix those separately.

@bergzand bergzand self-requested a review August 30, 2018 10:18
@bergzand bergzand added Area: network Area: Networking Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation Area: drivers Area: Device drivers labels Aug 30, 2018
@SemjonWilke
Copy link
Member Author

hey @bergzand are you still looking into this?

@bergzand
Copy link
Member

hey @bergzand are you still looking into this?

Thanks for the ping :)

I'm missing socket_zep (cpu/native/socket_zep) in the list of changed drivers. Changes look good otherwise. Thanks for cleaning up.

@@ -151,6 +151,13 @@ int netdev_ieee802154_get(netdev_ieee802154_t *dev, netopt_t opt, void *value,
res = sizeof(l2filter_t **);
break;
#endif
case NETOPT_MAX_PACKET_SIZE:
assert(max_len >= sizeof(int16_t));
*((uint16_t *)val) = (IEEE802154_FRAME_LEN_MAX -
Copy link
Member

Choose a reason for hiding this comment

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

/home/hydrazine/dev/RIOT/drivers/netdev_ieee802154/netdev_ieee802154.c:156:27: error: 'val' undeclared (first use in this function)

I guess this should be value instead ;)

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh oh. I fixed this right after PR, but i forgot to push it, sorry.

Copy link
Member

Choose a reason for hiding this comment

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

No worries.

In the future please use a fixup commit instead of force pushing. Using fixup commits makes it easy for the reviewer to track changes between revisions and they can be automatically squashed before merging.

Copy link
Member Author

Choose a reason for hiding this comment

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

You are right. This was meant to go into the PR and i just missed the push, this was allready fixed before and i just pushed it now without touching it, thats why i commented it. Sorry for the inconvenience :)

Copy link
Member

Choose a reason for hiding this comment

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

It's fine, luckily for me this PR is not that big :)

@SemjonWilke
Copy link
Member Author

SemjonWilke commented Sep 20, 2018

@bergzand good to sqash?

cpu/native/socket_zep/socket_zep.c Outdated Show resolved Hide resolved
@PeterKietzmann
Copy link
Member

@bergzand did you start testing? I could support a bit now

@PeterKietzmann
Copy link
Member

PeterKietzmann commented Sep 25, 2018

To track some ping6 based tests that I'm gonna provide next.

A: ping6 1000 <link local IPv6 addr> 0 0 0
B: ping6 1000 <link local IPv6 addr> 150 0 0

@bergzand
Copy link
Member

@PeterKietzmann Thanks for taking over with the testing! I'm mostly curious whether all radios still use the same MAX_PACKET_SIZE when transmitting

@SemjonWilke
Copy link
Member Author

Oh, you can proceed testing, but maybe i can get rid of some more defines. On first glance it seems that I may also delete KW2XRF_MAX_PKT_LENGTH, CC2420_PKT_MAXLEN, AT86RF2XX_MAX_PKT_LENGTH, CC2538_RF_MAX_DATA_LEN. I'll have to get into this later today.

@PeterKietzmann
Copy link
Member

Then please add the WIP label next time!!! I will stop testing now. Faced other problems when putting my hands on the cc2420.

@PeterKietzmann PeterKietzmann added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Sep 26, 2018
@SemjonWilke
Copy link
Member Author

SemjonWilke commented Sep 26, 2018

Then please add the WIP label next time!!! I will stop testing now. Faced other problems when putting my hands on the cc2420.

@PeterKietzmann Can you please specify the problems?
EDIT: Or was your problem unrelated to this PR?
This PR was not supposed to be WIP, opposing to that I expect it to work properly.

Also it was not obvious to me that the named defines are redundant because, even though they are just the same as IEEE802154_FRAME_LEN_MAX, they all are used and hence substituting them did not appeal to me in the first place.
When i thought about it earlier today, I had another view on the code and changed my mind.
If this is a concern for anyone i'd prefer to provide another cleanup PR for that so this will not interfere with anything presented here.

@PeterKietzmann
Copy link
Member

Unrelated to your changes, see #10043

@bergzand
Copy link
Member

@PeterKietzmann Am I correct when I conclude that this PR doesn't break/impact connectivity and packet loss? To prevent this PR from getting stuck, how about we merge this and assume that @SemjonKerner is going to provide a cleanup in the near future to remove the rest of the obsolete defines.

@SemjonKerner Does this make sense? Is this okay with you?

@SemjonWilke
Copy link
Member Author

@bergzand I don't expect this PR to be the reason for the observed problems with packet loss, and i think the tests suggest the same. So yes, this makes sense to me.

@bergzand bergzand added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet labels Oct 15, 2018
@bergzand
Copy link
Member

@SemjonKerner Murdock is pointing out a few build errors with socket_zep

@SemjonWilke
Copy link
Member Author

@bergzand fixed. Just a missing typecast.

@PeterKietzmann
Copy link
Member

Oh, you can proceed testing, but maybe i can get rid of some more defines

This let me conclude you were about to continue working on this PR. The problems I pointed out don't relate to this PR. As one can see, results w/ and w/o are "the same". I won't block this PR.

@bergzand
Copy link
Member

This let me conclude you were about to continue working on this PR. The problems I pointed out don't relate to this PR. As one can see, results w/ and w/o are "the same". I won't block this PR.

Thanks, and especially thanks for the thorough test you did on this!

@SemjonKerner Please squash

@bergzand bergzand merged commit 9a3e9ee into RIOT-OS:master Oct 16, 2018
@bergzand
Copy link
Member

Thanks for the cleanup @SemjonKerner!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: drivers Area: Device drivers Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants