NACK in it's current state -> IMHO netdev2 is link layer agnostic, and I don't like a solution, in which ethernet devices have to hand over radio specific information (at least conceptual, though in practice you would just pass NULL I guess).

Now lets see if there is a better solution: if we would keep strictly to the plain concept of netdev(2), one would acquire the RSSI and LQI values on demand using the get() function. Now this would mean to calls to get on each received packet - screw that, too inefficient...

Adding an additional function like get_rx_info() can I think also be ruled out, as we don't want to bloat the interface...

So how about generalizing this PR just slightly:

int (*recv)(netdev2_t *dev, char* buf, int len, void *info);

and make the type of info depend on the type of device (which you can find out with get(NETOPT_DEVICE_TYPE)). So all 15.4 devices could then pass an instance of

typedef struct {
    uint8_t rssi;       /**< RSSI of a received packet */
    uint8_t lqi;        /**< LQI of a received packet */
} netdev2_radio_info_t;

when receiving a packet?

This paradigm could be even extended to sending packets. So by changing the send function to

int (*send)(netdev2_t *dev, const struct iovec *vector, int count, void *info);

we could give link layer specific information back, as for example the number of retries (if available...). But if this makes sense we should discuss separately...

Now lets see if there is a better solution: if we would keep strictly to the plain concept of netdev(2), one would acquire the RSSI and LQI values on demand using the get() function. Now this would mean to calls to get on each received packet - screw that, too inefficient...

I'm with you on that. I already need to call a lot of get, with netdev2 (to get the source address and its length e.g.), I like to keep this to a minimum.

So how about generalizing this PR just slightly:

int (*recv)(netdev2_t *dev, char* buf, int len, void *info);

and make the type of info depend on the type of device (which you can find out with get(NETOPT_DEVICE_TYPE)). So all 15.4 devices could then pass an instance of

typedef struct {
    uint8_t rssi;       /**< RSSI of a received packet */
    uint8_t lqi;        /**< LQI of a received packet */
} netdev2_radio_info_t;

when receiving a packet?

I had it like this first, but than decided it to do it as it is currently in the PR… don't know why I changed it... Will do.

This paradigm could be even extended to sending packets. So by changing the send function to

int (*send)(netdev2_t *dev, const struct iovec *vector, int count, void *info);

we could give link layer specific information back, as for example the number of retries (if available...). But if this makes sense we should discuss separately...

Symmetry is always better :-). I think I will provide this API change, but not the type needed for it for now.

Done.

looks ok to me. One thing we should spend a thought about is the naming scheme for the info types (as netdev2_radio_recv_info_t). I think it makes sense to couple them somehow to the netdev types, so that you can at least guess the correct info type before you have to read any documentation. What I mean is something like netdev2_802154_rx_info_t, netdev2_cc110x_rx_info_t, etc, while the two might as well be type deved to the same structure... Makes sense?

@haukepetersen ping?

I guess @haukepetersen meant something like:

struct netdev2_radio_rx_info {
    uint8_t rssi;       /**< RSSI of a received packet */
    uint8_t lqi;        /**< LQI of a received packet */
};

typedef struct netdev2_radio_rx_info netdev2_ieee802154_rx_info_t;
typedef struct netdev2_radio_rx_info netdev2_cc110x_rx_info_t;

Done and adapted existing drivers. Will introduce netdev2_ieee802154_rx_info_t in netdev2_ieee802154.h as soon as #4645 gets merged (or if this one gets merged first I will adapt it here).

What's the intention of the info parameter for the send function? Any use case in mind?

From #4648 (comment):

This paradigm could be even extended to sending packets. So by changing the send function to

int (*send)(netdev2_t *dev, const struct iovec *vector, int count, void *info);

we could give link layer specific information back, as for example the number of retries (if available...). But if this makes sense we should discuss separately...

What happened to the good old: "implement that when there is a (concrete) need for it"? ;-)

I did not implement anything, I just provided an API to do it ;-)

What happened to the good old: "implement that when there is a (concrete) need for it"? ;-)

Now looking at this PR again I think @OlegHahm has a point -> how about we keep the send function untouched for now and add it when needed?

Also I would like @kaspar030 to take a look at this change and get his approval.

how about we keep the send function untouched for now and add it when needed?

Done

ACK

Rebased and squashed.

ACK also from my side.

Fixed some errors and squashed immediately

Can someone look over the changes and say if they are still okay?

Looks ok to me.

The doc says the info's datatype is "depending on the device type". That means NETDEV2_DEVICE_TYPE? Or how can I find out which type exactly?

By name ;)