Actually this PR reminds me a bit of what we once had in FeuerWare/µkleos and is for historical reasons still defined here: https://github.com/RIOT-OS/RIOT/blob/master/sys/include/radio/radio.h

I'm not a fan of function pointers though. However, I see that for MAC protocols that might be more sensible than using IPC.

Yes, as a MAC protocol developer, it would tremendously simplify my life. I can't really use the FeuerWare API since it doesn't separate the MAC and physical layers...
And as I told you, using function pointers (that is: code, stored in Flash memory) instead of IPC should -- I hope -- also prove useful to limit RAM usage. I must say that on my tiny little MSP430 devices and their 8 KB RAM, I always fear to run out of memory...

Moreover, implementing this API doesn't prevent (unless I missed something) the ability to continue using the IPC mechanism, for people who prefer elegant solutions -- and have higher-end devices ;)

@thomaseichinger et al:
Would it make sense to streamline this for the requirements of openwsn?
That is: split load and and send functions if I remember it correctly.

@LudwigOrtmann
By "splitting load and send", do you mean having something like this:

void (* load)(void *buf, unsigned len); // load transceiver TX buffer
radio_tx_status_t (* send)(void); // send what's inside transceiver TX buffer

instead of the current send() function?

Rebased on master

@rousselk
Almost - the send function could/should still exist, but just call those two.
Maybe a return value for the loading wouldn't hurt either, but that's not for me to say ;-)

Here you go. Also corrected a couple of mistakes.

@thomaseichinger is this what you need?

Yes, this would meet my requirements on a radio driver regarding OpenWSN.

Rebased on master.

Corrected documentation, and completed the send() and load_tx() prototypes---using a new ieee802154_node_addr_t type.
The API specification should be complete now...

Rebased on master (again).

Is this PR ready to be merged?

I can't really judge the content, but as comments have been addresssed, you could squash the commits already.

@authmillenon do you have any opinion on this?

Squashed commits together. Ready to be merged if everyone agrees.

There might be some corner cases, where this driver model might not be useful (e. g. multiple receive threads), but this can be easily circumvent with some kind of multiplexing layer (which might be needed at some point anyways, if we get more network stacks ;-)), maybe some adaption of net_if would suffice for that.

in any way: ACK.

Well, it seems this PR is ready. @OlegHahm @thomaseichinger no objections?

looks good to me, ACK

Let's move on, then!