drivers: Introduce a general interface for network device drivers

[miri64]

This is thought to merge the concepts of @rousselk's #925 and my #1448. It also addresses #1448 (comment)

Things to do:

• make ieee802154_radio_driver_t subclass of net_dev_driver_t
• rename to naming scheme where renaming is due
• adapt already implemented drivers
• add native support
• provide tests

Dependency graph:

… …
| |
| * #1448
| |\
* | | #1733
| * | #1732
| | * #1731
| |/
|/
* #1492

[miri64]

Can someone with a cc2420 board test if this works?

[miri64]

@LudwigOrtmann you might want to review, too, now that I started to adapt nativenet for net_dev.

[LudwigKnuepfer]

I'd like to but I'm mostly out of resources right now and the PR is so intimidating.

[miri64]

When I'm done with native I'll write some tests :-)

[miri64]

Rebased and squashed. Will provide tests tomorrow.

[miri64]

Rebased and squashed

[miri64]

Had to rebase and used the chance to squash some commits.

[miri64]

I'm done \o/

[LudwigKnuepfer]

No you're not, buildtest fails for tests/net_dev =(

[miri64]

Orrr, MSP430-libc! Was kannst du eigentlich?!!?

[miri64]

Now it should work.

[miri64]

I do not really understand why the unittests fail oO. On my machine everything is running smoothly

[miri64]

ping?

[miri64]

Needed to rebasedue to Makefile-change in #1714

[miri64]

Split into 4 PRs (including this one) to simplify review (hopefully). Dependency graph is as follows:

… …
| |
| * #1448
| |\
* | | #1733
| * | #1732
| | * #1731
| |/
|/
* #1492

[rousselk]

Maybe I'm going to say something stupid, but... doesn't this "one size fits all" API change make everything more complex? I kind of feel that the drivers/include/netdev/base.h file contains many elements that have few relations to each other (e.g.: very low-level details like hardware addresses in host byte order, along with high-level layers like TCP or CCN)...This "semantic mix" makes me uneasy.

Isn't there also a risk of increasing code size? Every layer will have to "cope" with elements they are not related to... It may cause a problem if one wants to use the whole network layer on limited devices (like Telosb for example)

However, since I couldn't attend netxork-related meetings, maybe were these issues already discussed and decisions taken?

[miri64]

There is no semantic mixing IMHO. If a device does not support and option it can always return -ENOTSUP, as stated in the documentation (and thus does not increase code size that much). Yes, maybe it is complicated by giving you all these options, but keep in mind that this is the in most (if not all) use-cases just the backend for the network stack. Currently the later communicates with the devices through the multiplexing transceiver interface, but this just doesn't cut it because:

1. it is historically grown from a cc1100-only interface.
2. it supports only 1 device of each type.
3. it just does not scale development-wise when we add more devices, since every new one will introduce another ifdef-path.

We know this is far from perfect, but I think this PR is a step in a better direction.

[OlegHahm]

Why packed?

[miri64]

because otherwise there would be alignment problems if you put it in a static array (namly pktbuf in #1638 ;-))

[OlegHahm]

tests/netdev on native:
Default netdev type and driver unknown!

[miri64]

Yes, because there are no devices implemented in this PR. Please refer to #1732 or #1733.

[OlegHahm]

Well, okay, ACK.

[miri64]

Squashed & rebased & waiting for Travis to be done

[OlegHahm]

Kicked Travis.

[miri64]

And go.