Skip to content

lwip: add support for common netif API #9343

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

Closed
wants to merge 2 commits into from

Conversation

miri64
Copy link
Member

@miri64 miri64 commented Jun 13, 2018

Contribution description

This adds support for our common netif API for lwIP. It is still WIP. TODOs:

  • implement option getting
  • add tests

Issues/PRs references

Addresses #9287

@miri64 miri64 added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Area: network Area: Networking Area: pkg Area: External package ports labels Jun 13, 2018
@miri64 miri64 requested a review from smlng June 13, 2018 15:33
@miri64 miri64 added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Jun 13, 2018
@miri64 miri64 mentioned this pull request Jun 13, 2018
8 tasks
@miri64 miri64 force-pushed the lwip/api/initial-netif branch from 9a91dc6 to 17aed2a Compare June 13, 2018 15:34
@tcschmidt tcschmidt requested a review from cgundogan June 16, 2018 00:25
smlng
smlng previously requested changes Jul 13, 2018
Copy link
Member

@smlng smlng left a comment

Choose a reason for hiding this comment

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

not some change requests but rather request for explanation 😉

res = dev->driver->get(dev, opt, netif->hwaddr,
sizeof(netif->hwaddr));
if (res > 0) {
netif->hwaddr_len = res;
Copy link
Member

Choose a reason for hiding this comment

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

could this actually be different then the one reported by the get above? I would rather think that if this get fails the hwaddr_len should be set to 0 to indicate an error, as we cannot do so due to void function.

Copy link
Member Author

Choose a reason for hiding this comment

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

Nope, I guess this is copy-pasta from the GNRC version (where I did it a little differently). Will do as you proposed.

Copy link
Member Author

Choose a reason for hiding this comment

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

In fact, error-checking isn't necessary here at all, since this function is only called if the address was set on the driver. If the driver doesn't allow for this, netif->hwaddr and netif->hwaddr_len shouldn't be changed anyway (which they wouldn't if get()/set() are implemented correctly by the driver ;-).

case NETOPT_IPV6_ADDR_REMOVE:
return sizeof(ip6_addr_t);
case NETOPT_IPV6_ADDR_FLAGS:
return sizeof(uint8_t);
Copy link
Member

Choose a reason for hiding this comment

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

maybe its too early, but can these are no-ops, right? Can you please explain the reasoning.

Copy link
Member Author

Choose a reason for hiding this comment

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

This is the WIP part of this PR ;-) the proper functions will be called here later.

switch (opt) {
#if LWIP_IPV6
case NETOPT_IPV6_IID:
return sizeof(eui64_t);
Copy link
Member

Choose a reason for hiding this comment

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

same as for the set_opt, I don't understand this - and I also think this is wrong because the docu says:

 * @return  Number of bytes written to @p value.

but here nothing is written to value, or did I miss something?!

Copy link
Member

Choose a reason for hiding this comment

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

and if this assumes value is 0: I would rather not count on that, and explicitly set the default value.

Copy link
Member Author

Choose a reason for hiding this comment

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

This is the WIP part of this PR ;-) the proper functions will be called here later.

Dito

@stale
Copy link

stale bot commented Aug 10, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Aug 10, 2019
@miri64 miri64 added State: don't stale State: Tell state-bot to ignore this issue and removed State: stale State: The issue / PR has no activity for >185 days labels Aug 10, 2019
@smlng smlng dismissed their stale review November 27, 2019 14:24

outdated, and PR still WIP

@miri64 miri64 added the State: archived State: The PR has been archived for possible future re-adaptation label Jan 16, 2020
@miri64
Copy link
Member Author

miri64 commented Jan 16, 2020

netif changed and is about to change more due to the rework efforts by @jia200x. Closing for now.

@miri64 miri64 closed this Jan 16, 2020
@miri64 miri64 deleted the lwip/api/initial-netif branch January 16, 2020 12:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: network Area: Networking Area: pkg Area: External package ports State: archived State: The PR has been archived for possible future re-adaptation State: don't stale State: Tell state-bot to ignore this issue State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants