netif: Initial import of a common network interface API by miri64 · Pull Request #6413 · RIOT-OS/RIOT

miri64 · 2017-01-18T16:27:09Z

Adaptation of @kaspar030's proposal in #5511.

miri64 · 2017-05-16T11:30:01Z

@kaspar030 I added the params-structs for the auto-initialization of netif to this PR, since I think it fits in here.

miri64 · 2017-05-23T14:38:19Z

Rebased to current master and refined documentation

Refine documentation

Simplify netif_type and start skeleton implementation

smlng · 2017-05-24T08:08:28Z

sys/include/net/netif.h

+ */
+
+/**
+ * @defgroup    Network interfaces


should be @defgroup net_netif Network Interfaces?

miri64 · 2017-05-24T14:54:04Z

I hit a wall when trying to port the auto-initialization for GNRC... (mainly questions like: "Where is the thread's memory stack stored and how is its size determined?" and "Where is the adapter struct stored?") Need to think about this a bit more :-/. Input is welcome.

miri64 · 2017-06-01T15:00:22Z

"Where is the adapter struct stored?"

For this question I basically have an answer (and had when I stated that question) already in my back-hand an answer, but this is related to my over-all GNRC overhaul.

smlng · 2017-06-06T19:19:23Z

sys/include/net/netif.h

+     */
+    const void *dev_params;
+    netif_type_t type;      /**< type of the interface */
+    const char *name;       /**< name of the interface */


is it necessary to have the name attached to every device?

I was thinking of something like a common prefix for certain netif_type_t types and let the system number them starting with 0. (Or instead of const char *name have a uint8_t name_prefix.) And then have map from type (or name_prefix ) to a char prefix (without a number), e.g. "eth" or "wpan" or maybe "gnrc"?

I hope you get what I mean 😕 ❓

Hi, I think that makes the initialization just more complicated, because then we need to keep track of how many interfaces are already initialized. The auto-initialization is already pretty complicated so let's not make things more complicated for a totally optional thing for most stacks (the only stack actually requiring a name at the moment is lwIP).

kaspar030 · 2017-06-07T10:14:11Z

Can you please elaborate what you intend to do with this interface?
Is this for auto-initialization only?
It seems a little odd to have a package dependent define in pretty central code.

miri64 · 2017-06-07T10:19:46Z

Can you please elaborate what you intend to do with this interface?
Is this for auto-initialization only?

For now I am only planing auto-initialization, yes. But long-term plans include a generalized ifconfig command (that's why netif_g/set_opt() exist) and maybe even further down the line sock_netif. But before any of that I'd rather want to clean-up GNRC's network interfaces (for which I do not need this necessarily).

It seems a little odd to have a package dependent define in pretty central code.

What define are you talking about?

kaspar030 · 2017-06-07T10:55:20Z

Maybe we should define first what needs to be configurable, find a nice way of representing that, and then code the initialization around that?

It seems a little odd to have a package dependent define in pretty central code.
What define are you talking about?

You've got #if defined(GNRC), #if defined(MODULE_LWIP_ETHERNET). It is certainly possible to do this without those defines.

IMO it would make sense to keep configuration within the stacks, come up with a way to configure which stack uses which network device, and let them handle it as desired.

miri64 · 2017-06-07T11:00:28Z

You've got #if defined(GNRC), #if defined(MODULE_LWIP_ETHERNET). It is certainly possible to do this without those defines.

I think these can be removed, the number in the enum is all what matters after all.

IMO it would make sense to keep configuration within the stacks, come up with a way to configure which stack uses which network device, and let them handle it as desired.

This is what this PR is about and that's exactly what I do in #7144.

miri64 · 2017-06-07T11:03:13Z

I think these can be removed, the number in the enum is all what matters after all.

Done

kaspar030 · 2017-06-07T11:59:54Z

I think these can be removed, the number in the enum is all what matters after all.

It's not about the define, it's about the dependency. As is, you'd need to edit netif if you'd like to use a previously unknown stack. That is unnecessary.

For auto-init, a shared initialization function and parameter definition just don't make sense anyways.

miri64 · 2017-06-07T15:54:53Z

It's not about the define, it's about the dependency. As is, you'd need to edit netif if you'd like to use a previously unknown stack. That is unnecessary.

As is it is, because currently the auto-initialization is per device, not per stack.

For auto-init, a shared initialization function and parameter definition just don't make sense anyways.

Another approach I was thinking about would be put all initialized netdevs into a linked list, and then iterating over that for a stack-specific initialization. But that would mean sizeof(netdev_t *) extra byte for each netdev (currently) just for initialization.

aabadie · 2017-06-23T08:30:16Z

I fear it won't make it for the release, postponed to 2017.10.

miri64 · 2017-10-05T08:11:46Z

Anyone care to review?

smlng · 2017-11-17T11:22:14Z

@miri64 I need some help/recap on this one: is it still on? And if so how does it fit with netif2?

miri64 · 2017-11-17T12:40:28Z

@miri64 I need some help/recap on this one: is it still on? And if so how does it fit with netif2?

It has nothing to do with gnrc_ netif2! This is a network-stack-independent API to network interfaces. After #7925 was merged this needs to be adapted, but for now: nothing here to see ;-).

smlng · 2017-11-17T12:56:33Z

thanks for resetting my mind 😄 So this could (or better should) wait until #7925 is merge anyways?

miri64 · 2017-11-17T13:01:34Z

thanks for resetting my mind 😄 So this could (or better should) wait until #7925 is merge anyways?

To quote my self "After #7925 was merged this needs to be adapted" ;-)

smlng · 2017-11-17T13:02:18Z

okay I think now I got it 😉

miri64 · 2017-11-17T13:56:49Z

For reference: since that is automated and I add all PRs related to #7925 to that project: https://github.com/RIOT-OS/RIOT/projects/6 gives you all related PRs (but ignore the TODO column, those are mostly notes for myself)

smlng · 2017-12-15T22:35:30Z

@miri64 any progress after #7925 is merged for some time now?

miri64 · 2017-12-18T15:11:45Z

No, but I'd like to redo this in a 2-phase approach.

provide a common API
provide a common initialization API.

miri64 · 2018-03-27T19:55:55Z

Let's clean this up! I'm going back to the roots in #8841.

miri64 added Area: network Area: Networking Type: new feature The issue requests / The PR implemements a new feature for RIOT labels Jan 18, 2017

miri64 assigned kaspar030 Jan 18, 2017

miri64 mentioned this pull request Jan 31, 2017

gnrc ipv6: append empty netif hdr for loopback #5247

Closed

miri64 force-pushed the netif/api/initial branch from 9a9c9c3 to 81c104e Compare May 16, 2017 11:27

miri64 and others added 2 commits May 23, 2017 15:32

netif: Initial import of a common network interface API

019a3c3

netif: add capability for auto-initialization

b913b3e

miri64 force-pushed the netif/api/initial branch from 81c104e to e032645 Compare May 23, 2017 14:37

fixup! netif: add capability for auto-initialization

b217fbe

Refine documentation

miri64 force-pushed the netif/api/initial branch from e032645 to b217fbe Compare May 23, 2017 14:39

fixup! netif: Initial import of a common network interface API

1d22331

Simplify netif_type and start skeleton implementation

smlng suggested changes May 24, 2017

View reviewed changes

miri64 added 2 commits May 24, 2017 11:05

fixup! netif: Initial import of a common network interface API

557e7a2

fixup! netif: Initial import of a common network interface API

06e1c55

miri64 added 4 commits June 1, 2017 17:32

fixup! netif: Initial import of a common network interface API

481896e

fixup! netif: Initial import of a common network interface API

8262475

fixup! netif: Initial import of a common network interface API

c25c220

fixup! netif: add capability for auto-initialization

350cdf9

miri64 mentioned this pull request Jun 6, 2017

gnrc_netdev: port to generalized netif auto-initialization #7144

Closed

smlng reviewed Jun 6, 2017

View reviewed changes

fixup! netif: Initial import of a common network interface API

78db92e

aabadie added this to the Release 2017.10 milestone Jun 23, 2017

smlng modified the milestones: Release 2017.10, Release 2018.01 Nov 16, 2017

kb2ma mentioned this pull request Dec 8, 2017

net/gcoap: Require interface for link local address in shell example #8223

Merged

smlng modified the milestones: Release 2018.01, Release 2018.04 Jan 18, 2018

This was referenced Mar 21, 2018

dhcpv6: Initial implementation of a client (with IA_PD support) #8796

Merged

netif: Initial import of a common network interface API (second try) #8841

Merged

miri64 closed this Mar 27, 2018

miri64 deleted the netif/api/initial branch March 27, 2018 20:00

Conversation

miri64 commented Jan 18, 2017

Uh oh!

miri64 commented May 16, 2017

Uh oh!

miri64 commented May 23, 2017

Uh oh!

smlng May 24, 2017

Choose a reason for hiding this comment

Uh oh!

miri64 May 24, 2017

Choose a reason for hiding this comment

Uh oh!

miri64 commented May 24, 2017

Uh oh!

miri64 commented Jun 1, 2017

Uh oh!

smlng Jun 6, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

miri64 Jun 7, 2017

Choose a reason for hiding this comment

Uh oh!

kaspar030 commented Jun 7, 2017

Uh oh!

miri64 commented Jun 7, 2017

Uh oh!

kaspar030 commented Jun 7, 2017

Uh oh!

miri64 commented Jun 7, 2017

Uh oh!

miri64 commented Jun 7, 2017

Uh oh!

kaspar030 commented Jun 7, 2017

Uh oh!

miri64 commented Jun 7, 2017

Uh oh!

aabadie commented Jun 23, 2017

Uh oh!

miri64 commented Oct 5, 2017

Uh oh!

smlng commented Nov 17, 2017

Uh oh!

miri64 commented Nov 17, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

smlng commented Nov 17, 2017

Uh oh!

miri64 commented Nov 17, 2017

Uh oh!

smlng commented Nov 17, 2017

Uh oh!

miri64 commented Nov 17, 2017

Uh oh!

smlng commented Dec 15, 2017

Uh oh!

miri64 commented Dec 18, 2017

Uh oh!

miri64 commented Mar 27, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

smlng Jun 6, 2017 •

edited

Loading

miri64 commented Nov 17, 2017 •

edited

Loading