@cgundogan integrated.

• updated
• rebased

I might have an idea to prevent having to copy the data to send into one continuous chunk before you send it: how about splitting the send function in three parts: prepare, load, and execute. This way you could call the load function with an data offset parameter multiple times and then call exec once all the data is loaded into the device buffer... The original send function could stay for convenience reasons, it would just call the three 'lower-level' functions.

Also I am not quite sure about the global functions you defined outside the eth_driver_t struct. I have the impression that they do not scale very well if you have multiple ethernet devices?!

... splitting the send function in three parts ...
I came to the same conclusion. Will change the interface accordingly.

Also I am not quite sure about the global functions you defined outside the eth_driver_t struct. I have the impression that they do not scale very well if you have multiple ethernet devices?!

Why not? Those functions are called with the device handle as parameter. Should be easy to dispatch to whatever the network stack needs.

load function with an data offset parameter

Do you think we can omit that parameter? The two drivers I have don't need it.

I didn't really follow the latest discussions on netdev and this stuff, but looking at the proposed interface that looks exactly how I remember netdev to look like. Now, that I look at driver/include/netdev again, I see that it became a little bit bigger over time, but still I don't really get the purpose/advantage of your interface. What dependencies are pulled in by netdev?

@OlegHahm ng_netdev pulls at least ng_pkt, ng_pktbuf, ng_netconf. All of them are not needed for a low-level driver. pktbuf alone disqualifies the interface for class-0 devices. And as you realized, the interface is nearly the same, just without those dependencies. That is exactly the purpose / advantage of it.

ng_netdev pulls at least ng_pkt, ng_pktbuf, ng_netconf.

Maybe I'm starring at the wrong files. Can you point me to these dependencies?

And as you realized, the interface is nearly the same, just without those dependencies. That is exactly the purpose / advantage of it.

Sounds completely reasonable to me. But this sounds to me as we should use this interface as a base and put additional features as a kind of add-on on top of it if necessary.

(Sorry if I discuss about this from a rather abstract level, but I don't have time to dig into the actual code too much.)

ng_netdev pulls at least ng_pkt, ng_pktbuf, ng_netconf.

Maybe I'm starring at the wrong files. Can you point me to these dependencies?

From ng_netdev.h:

#include "net/ng_pkt.h"
#include "net/ng_netconf.h"

Actually pktbuf is not a direct dependency, but ng_pkt.h states:
@note This type has no initializer on purpose. Please use @ref net_ng_pktbuf as factory.

Also the pktsnip_t is more complex than neccessary, forcing this additional complexity into every triver that uses ng_netdev.

Sounds completely reasonable to me. But this sounds to me as we should use this interface as a base and put additional features as a kind of add-on on top of it if necessary.

Which interface is "this" in that sentence? :)

Ah, I was indeed looking at the wrong file. Why is device driver interface specified in sys? Hm, ng_netconf.h is just header including some enums, so this dependency is bearable.

For the the other depencies, I agree that this is a bit unfortunate. Can we find a way to abstract from this?

I agree, that it may make sense to have different network stacks with different focuses (class 0 devices or class 1+ devices, for instance), but on the device driver level, I would have assumed that it is possible to define a basic set of functions that can (almost) always be satisfied.

Which interface is "this" in that sentence? :)

Sorry, I meant the interface you propose in this PR.

Why is device driver interface specified in sys?

You're saying it should move to drivers/include?

Hm, ng_netconf.h is just header including some enums, so this dependency is bearable.

Agreed. Still personally I always prefer not to dictate implementation through interface, just for the flexibility.

I agree, that it may make sense to have different network stacks with different focuses (class 0 devices or class 1+ devices, for instance), but on the device driver level, I would have assumed that it is possible to define a basic set of functions that can (almost) always be satisfied.

Totally. That's what I tried with this interface. Should be simple to extend it so it also works for radio devices. And it can already be used with the ng network stack.

You're saying it should move to drivers/include?

That seems the natural place for me to look for a device driver interface - and that's the place where I searched for it.

Totally. That's what I tried with this interface. Should be simple to extend it so it also works for radio devices. And it can already be used with the ng network stack.

@haukepetersen, @authmillenon, do you have any opinion on this?

@OlegHahm I'm also of the opinion to put it into drivers (as the legacy version of netdev you found there indicates). @haukepetersen however put it into sys/include/net since he feels it more belonging to the network architecture than the device architecture. The arguments for and against drivers/include or sys/include/net weigh each other pretty much out, I guess.

His argument was more or less, that yes, it's device related and it presents an API for a driver (that can in theory be directly connected to the hardware), but things like this PR and previous discussions not to enforce ng_netdev on devices, mainly because its strong dependency to ng_pktbuf, show that it is more an API for the network stack to speak with a device.

Does this reflect your argument @haukepetersen?

Why is it that dependent on ng_pktbuf? In the end the device just needs a pointer to some data (for sending) or a pointer to some buffer where to copy data (for receiving).

IMO we should have network device interface (i.e. netdev) in drivers/include that can be used as a basis for all network stacks. Otherwise (being dependent on RIOT specific structures) we would have to implement a device driver for each network stack like OpenWSN.

@OlegHahm because a network device is required to at least release a sending packet from packet buffer, because it is the last one touching it. Apart from it sure, you can just use arbitrary ng_pktsnip_t pointers, but in practice it makes most sense to put them into the packet buffer directly to reduce overhead.

I spend some more thoughts about these driver interfaces the last days, but I have not come up with a clear opinion, yet. I understand @kaspar030s thoughts about netdev being too complicated/having too many implications on the actual implementation, but I don't see them necessarily as too bad...

I guess creating true low-level driver interfaces for ethernet, ieee802.15.4 etc and mapping the netdev interface on top of these would be an option. This is in my opinion however only valid, if we do not introduce addional copying of data and/or addiontial depth in function call hierarchy... Otherwise we would take efficiency away from the netdev interface.

My question about your opinion was more about the directory of ng_netdev.h.

@OlegHahm I think this is squashable?

sure, go ahead

• squashed
• rebased

The last two comments are no stoppers. I leave it to you, @kaspar030, if you want to address them. Otherwise go ahead with merging.

-rebased
-addressed @OlegHahm's doxygen comments

go, travis, go!

driver_nrfmin is failing, but this is unrelated to this PR. Go as soon as it goes … red

GO.

🎉 🍻