netdev: introduce additional flags

[OlegHahm]

A first use of these flags is introduced to indicate the interface as being wireless which might be a useful information for upper layers.

[OlegHahm]

I'm not happy to introduce an additional field in netdev_t, but I couldn't think of another solution. The information if an interface is wireless or not is static and using NETOPT seemed pointless to me.

[kaspar030]

Do you need this for something right now? I'd rather integrate this into netdev2.

[OlegHahm]

It's needed for a new version of #3622, i.e. doing NDP properly for wireless medium,

[miri64]

I'd prefer to stay with netopt to keep the interface clean.

[OlegHahm]

And the change itself is (as you can see) super small. So, integrating this in netdev2 should be easy.

[OlegHahm]

IMO using netopt is completely overkill here.

[kaspar030]

@OlegHahm agreed, the change is small, so I don't mind.

[OlegHahm]

(And it would be a misuse, since being wireless is not an option or anything configurable.)

[miri64]

I'm still somewhat confused about why we need that however. WiFi is on IP level not seen as wireless and the rest of the radios we aim to support use 6LoWPAN. 6LoWPAN uses its own ND (which is not merged yet) so why do we need it for #3622

[OlegHahm]

WiFi is on IP level not seen as wireless

Why not?

[kaspar030]

@OlegHahm because it does magic to behave like a wire.

[miri64]

Then how do you get the information to the upper layer, when not using netopt? netapi has no other means to carry information to other layers.

[OlegHahm]

But in reality it does not behave like Ethernet and RFC5889 applies (actually, I guess that it has been written with specifically 802.11 in mind).

[OlegHahm]

Then how do you get the information to the upper layer, when not using netopt? netapi has no other means to carry information to other layers.

Will introduce this in a follow-up PR as an additional flag in netif.

[OlegHahm]

Oops, forgot to commit ng_netdev.h

[OlegHahm]

Hm, actually turned out to be more complicated since getting static information from the interface seems to be not foreseen in the stack...

[miri64]

Yes, that's what I mean't. We really need to think if we make such exceptions to the API because it is 'overkill'. IMHO your flag solution is the right way to store the information on the device (I would however use the device's private flags and not introduce a new field to netdev). But we should use netopt regardless to get the information to the upper layer.

[miri64]

Otherwise, we get quickly into situations we had in the old stack, where every layer does it's own thing and nobody has any clue how to fix stuff.

[miri64]

(Because it is overkill to have a netopt for every flag, I argued month ago to have a NETOPT_FLAGS value for that and add the operations add/remove to the interfaces, when the interface was still in development, but that was voted down, so I guess we have to live with this situation now).

[OlegHahm]

I partly agree, but I'm still reluctant to go through netopt only to retrieve static information from the device.

[miri64]

We do it for the frame length too. So the harm is already done ;-P

[miri64]

Oh I was mistaken, you don't need to store it dev internally if you go over netopt. You can just return NETOPT_ENABLE/NETOPT_DISABLE when using it.

[cgundogan]

Could you also use @name with an appropriate description and wrap the #define in @{ .. @}?

[thomaseichinger]

I support @authmillenon on this, it should be done using netapi. The interface wont most probably not change so this shouldn't get fetched too often.

Anyway, the flag is not set for the xbee driver.

[OlegHahm]

Ok, I try to come up with a better approach - in the worst case misusing netopt.