gnrc nettype: always include all nettypes

[OlegHahm]

Even if an application cannot process a certain protocol, it might be able to handle it somehow.

[miri64]

Can you chalets the buildsizes please? Will explain tomorrow.

[miri64]

it might be able to handle it somehow.

For this demux_ctx exist.

[OlegHahm]

What if there is an Ethertype set to IPv6 in a L2 packet for instance? And what about #4189 (which was the reason for me to introduce this)?

[OlegHahm]

About 32 bytes more ROM usage and 8 bytes more RAM usage on Cortex-M platforms.

[miri64]

What if there is an Ethertype set to IPv6 in a L2 packet for instance? And what about #4189 (which was the reason for me to introduce this)?

GNRC_NETTYPE_UNDEF should suffice for both cases (in #4189 we can make this easy to read by defining a define checking the whose value is either GNRC_NETTYPE_UNDEF or GNRC_NETTYPE_UDP). The problem is, that the size of the array for storing the gnrc_netreg is linked to GNRC_NETTYPE_NUMOF so we would disregard this low-key optimization for this very little bit of comfort in gnrc-internal programming.

[OlegHahm]

I have to admit that I don't like this, but cannot think of another solution right now (except for ugly ones). I don't understand your solution for #4189 though, can you make a proposal?

[miri64]

I discussed this with @emmanuelsearch and @haukepetersen today, and we came to the decission that your solution wouldn't really hurt that much: As you've said the additional RAM usage is minimal (though I'm not quite sure which app you mean). On the plus side it would make a lot of code easier to read, so let's go for it.

[miri64]

ACK if OP is okay with reopening this PR and Travis is happy.

[OlegHahm]

Oops, sorry, I think I tested with gnrc_border_router. So, it's probably only the RAM overhead for one additional nettype (UDP) in this case.

[miri64]

Did you re-test with other set-ups @OlegHahm?

[OlegHahm]

Not yet. Will do ASAP.

[miri64]

Any news here?

[OlegHahm]

Nope.

[miri64]

Then I would like to close this PR, since I imagine it to be bigger for more than one nettype.