UDPEcho compile error with IRIS platform about tinyos-main HOT 11 OPEN

This is a valid issue. I'm accepting it and we will get this in right after the 
2.1.2 release.

NB: since IRIS (rf2x) does not currently support all of the addressing modes 
needed for 6lowpan, this is not critical. 

Can I ask what you're referring to with "addressing modes" for the RF2xx? Is it 
the fact that Ieee154{Message,Packet}Layer in rfxlink only supports short 
addresses?

Yes -- to support 6lowpan correctly we need to support extended addressing 
mode.  For the CC2420 I implemented this by having the 6lowpan compressor 
generate complete 802.15.4 frames (with extended addresses, if required), and 
then adding a raw frame interface to the radio.  The only changes required to 
the driver were to configure the hardware address recognition to also accept a 
64-bit address, and to look for the address in the right place.

Yep, I saw the lib6lowpan frame preparing, and re-used that for the (hackish) 
patch for enabling BLIP on an RF212 which I posted to the -help list a little 
while ago (thread "[Tinyos-help] BLIP 2.0 with RF230/RF212"). Currently the 
RF212 driver doesn't implement hardware filtering, so I didn't even need to 
tweak that.

I'm just about to start work on making Ieee154{Message,Packet}Layer 
extended-address aware for our use here. If you have any requests or comments 
on how it should be done to have the highest chance of being accepted back, 
please do let me know. In the mean-time I'll opt for maintaining backwards 
compatibility (even though I'd like to change the existing interface to take a 
short/ext address structure/union).

That's cool. We had an enormous amount of discussion about this on -devel a 
while back, and then we fell down on the follow through...  It would be great 
to get this going.  My suggestion at this point would be to have a consistent 
raw frame interface which all radios using 802.15.4 framing can implement; we 
can then add a separate component which is platform independent and prepares 
frames for submission using the raw interface.  The real complexity comes from 
dealing with the fact that the headers may be variable-length.  This is exactly 
the issue we spent so long wrestling with in blip, in fact.  Anyways, I can't 
speak for core or anything, but that solution seems reasonable to me.

Thanks for the pointer to the -devel discussion. Was there a TEP (or draft 
even) written up as a result that I could use as a guide? Going on the email 
thread, it sounds as if it might be okay to change the API exposed by the 
Ieee154*Layer interfaces... I'll see how the code feels once I get into it.

In terms of having a consistent raw frame interface, I fully concur. I did note 
that there is a lot of naming confusion in the code around BareSend, Send and 
Ieee154Send.

In the hope of this being useful to the community, I've attached the changes we 
made here to extend the Ieee154*{Layer,Address} to support extended 15.4 
addresses. The patches are against our tree, which is based on the RF212+BLIP 
patch I posted to -help a while ago. I don't expect them to apply cleanly to 
trunk (sorry), but hopefully it's close enough to save a lot of time should you 
want to make use of our work.

To summarize the patches:

- I kept things fully backwards compatible (I believe), but added 
get/setAddrExt() functions as well as get/setAddrAny() to handle either case.

- As far as possible I've avoided copying, but I am returning extended 
addresses by value rather than pointer in order to keep a consistent interface 
with the existing short address interface.

- I introduced an ieee154_base_header_t with only the fcf/dns/destpan, and am 
using that instead of the ieee154_simple_header_t. Things which relied on 
sizeof(ieee154_simple_header_t) now calculate the length as appropriate. A side 
effect of this is that the header fields have to be set in order, and before 
the payload is added or things might get overwritten. I haven't encountered any 
places where this is the case, but it's a big caveat. Unfortunately I see no 
way around that limitation.

- The Ieee154Address interface was made async rather than duplicate needed 
functionality in the Ieee154*Layer components.

- The Ieee154*Layers no longer use any ActiveMessageAddress but rather 
Ieee154Address (the AM group being 8bits vs the expected 16bits in a PAN ID bit 
us earlier I might add).

People interested in BLIP support for IRIS should check out this tree:

https://github.com/mmaroti/tinyos/tree/blip

If this works, then I will commit it to the tinyos-main