Networking update: general refactoring, unifying EMAC, multi-if

[bulislaw]

WORK IN PROGRESS

Description

It's still work in progress, most of the changes were done some time ago, but I've decided to create the PR so we can start discussion and other people can start contributing. Probably contains a lot of issues ;)

General networking update, including:

• Porting ethernet to EMAC
• Updating EMAC to enable multiple interfaces
• Untangling networking classes, making the abstractions a bit clearer to follow, etc
• General refactoring
• Removal of DEVICE_EMAC flag and introducing DEVICE_ETH and DEVICE_WIFI

Roughly the mbed OS networking represented below. It's 'sort of' a class (abstraction) diagram, the arrows represent, any kind of, associations, and may not be complete, but represent the most important connections.

DISCLAIMER Connections on the diagram (and the whole diagram really) is just conceptual simplification, they don't represent things like callbacks which may make the connection in both directions. It should be useful to illustrate how the things are put together and interact, rather then provide complete and formal picture. aka pseudo-UML.

Status

IN DEVELOPMENT

Todos

• feature_lwip-tests-mbedmicro-net-connectivity fails on K64F
• Clean up magic numbers (eg timeouts) from LWIP adaptation code
• Refactor mbed_lwip_arena (make it not global?)
• Move HW specific EMAC files from LWIP to target code (it's HAL now)
• Rethink WiFiAccessPoint class name, it'll be confusing when we add AP mode
• Update all ethernet drivers to use EMAC
• Figure out ETH WIFI flags (do we need them? in what form? do we need LWIP at the same time?)
• ...

Todo but possibly after this PR

• Porting guide/docs
• Add 'NetworkFactory' to produce build in interfaces
• Port the new/better K64F EMAC driver
• Port existing networking tests to work with WiFi
• Generic MAC address generation API for NetworkInterface

CC

@geky @kjbracey-arm

[geky]

This is looking good! Still working through reviewing it. Also ccing @c1728p9

[bulislaw]

@geky btw when you'll have time to work on the EMAC stuff, feel free to push to this branch.

[kjbracey]

@hasnainvirk, @TuomoHautamaki

[mikaleppanen]

@mikaleppanen

[kjbracey]

What do DEVICE_ETH and DEVICE_WIFI actually mean? I want to be clear on that.

DEVICE_EMAC was odd, because unlike all the other DEVICE_XXX, it didn't seem mean anything positive, as far as I could tell - the target didn't directly provide "emac" calls - it was only used as library option hint to the LWIP/NSAPI code to tell it not to look for its own built-in target driver.

Looking at this, I'm not sure what DEVICE_ETH currently means, but it would seem logical that it could mean "platform provides provide mbed_emac_eth_default"? And hence EthernetInterface default constructor is provided? If DEVICE_ETH isn't defined, you should still be able to have plug-in modules(s).

Do you even need a define? How about just a weak mbed_emac_eth_default? It's maybe not the way the rest of the mbed HAL works, but emac already isn't.

[kjbracey]

Feeling quite positive on this, from what I've managed to take in so far - seems to be a sensible completion of the emac concept which wasn't fully realised.

The diff is going to conflict greatly with the work on the cellular stuff being aimed at 5.5, which had to rework lwip_stack's connect logic. I'm hoping this is aimed at 5.6 or later.

But the wider design approaches fit well - we have a similar concept about having an "mbed_ppp_attach" allowing a modem device to attach itself to the PPP driver of whichever stack is present, much like this attaches emacs. We should align our naming with the mbed_ipstack prefix.

Given the amount of design effort going on here, I would like to see potential design glitches shaken out by attempting a Nanostack implementation sooner rather than later.

[bulislaw]

@kjbracey-arm I'm afraid it's also targeted for 5.5 (it seems that lesson of 5.2 didn't worked) and we still don't know schedules between teams and don't consider clashes like that.

As to the flags, EMAC flag was a temporary thing to select between 'old way' and Emac APIs. The ETH and WiFi flags are not really necessary, we could do without them in some other way. That would probably require some work and tweaking (like defining some weak symbols as you mentioned) or even dynamically pluggable interfaces on bootup time.The way the mbed build system works (or at least I hope I don't misunderstand how it works) not used symbols should be stripped and having the 'infrastructure' present for all builds, even for targets without physical capabilities present shouldn't be a problem. Then again it wouldn't solve 'pluggable' hw modules, as we still need to define LWIP. Also that would expose us for potential runtime, hw not present errors, rather than favored by mbed HAL build time errors.
Personally I find eth/wifi flags cleaner and more descriptive than LWIP, right now we have them all at the same time, but it would possibly make sense to set 'default' stack flag automatically when, at least, one of the networking options is selected.