In general I like the idea, but I'm conflicted if

• overhead might be increased by this
• making the connection protocol <=> module is such a good idea (think dual-stack with cc3000 e. g.)

• overhead might be increased by this

I think the contrary is true, as the network modules do not have to care about storing PID's anymore -> see removed code in netapi and nomac...

making the connection protocol <=> module is such a good idea (think dual-stack with cc3000 e. g.)

You have to think of protocol more as network module, so we could add a module CC3000_UDP or something.

You have to think of protocol more as network module, so we could add a module CC3000_UDP or something

This will definitely increase code overhead. Instead of: "give me all UDP threads" it would be "give me UDP1, UDP2, UDP3" and ideally (not) with an humongous tree of #ifdefs which make the code just not fun anymore.

In general I see a lot of reintroduction and requirements of #ifdefs in your rework of the model (not only here). I was under the impression (and already stated this multiple times) however, that one of the major goals of the refactoring was to reduce them, since one of the lessons learned in the transceiver API was that they just don't scale and make the code a pain to read...

On a more constructive note: how about making the registry a list of (kernel_pid_t, kernel_pid_t, pkt_proto_t) tuples, where the first ist always the lower and the last always the upper layer thread. This way we identify implementations by their PIDs and specifications by an arbitrary number that is independent of the implementation as before.

There is also the matter of demultipexing identifiers (next header identifiers in IPv6, Ports in UDP/TCP) that is missing from here.

Hm, I see it completely on the contrary: For one I don't see any #ifdefs popping up, except on one single, central location, namely in netmod.h.

I also don't see the overhead: Why would you do something like: give me all UDP threads?

Ok, UDP might have been a bad example, but take for example Broadcast in IP: "give me all MAC threads".

It's also still unclear to me: If I have a e.g. a cc110x device with a nomac control thread, would I choose NETMOD_CC110x or NETMOD_NOMAC. If the first is the case first, how would I than differentiate between two cc110x that would run in a setup, where they use to different MAC implementations (since we might want to run experiments like this, this might be a realistic scenario)? And if the latter is the case, how would I differentiate the radios, say on a gateway between a cc110x network with nomac and an IEEE 802.15.4 network with nomac?

And how would I find out which address to use / which header (if we decide upon it) to use if the NETMOD_NOMAC option is true, or if the NETMOD_CC110x option is true, but the intermediate MAC layer has it's own header types.

It's also still unclear to me: If I have a e.g. a cc110x device with a nomac control thread, would I choose NETMOD_CC110x or NETMOD_NOMAC

You wouldn't use either of them :-) As interfaces are are accessed by there interface identifier, thats what you use. So if you have a standard IP address you want to send to, you ask your neighbor table to give you the interface id for that device. You ask then the netreg for the PID of that interface. In case of multicast/broadcast, the neighbor/forwarding table gives you a list of interface ID's you can lookup.

as I said, it's more or less pseudo-code. I will only start to make it work when we really decide to run with this concept...

Can we close this after #2404 got merged or do you plan to use this for a somehow optimized version of netreg?

this PR is it's obsolete.