[Tinyos Core WG] Re: Adding fields to structs

[Philip Levis]

On Apr 7, 2007, at 1:24 AM, Kevin Klues wrote:

> Fair enough.  It just sems like these sorts of issues always seem to
> get pushed under the rug and I wanted to make sure it was seriously
> discussed at some point.

After the TTX, be sure to remind me to put it on the agenda.  
Generally, things aren't pushed under the rug as much as someone  
suggests other people do a lot of work.

Here are some fundamental questions which would need to be answered:

1) How does ordering work? If there is no ordering specification,  
then you cannot link two object files that were compiled separately:  
they might have different orderings in the extensions. I know this is  
rarely an issue with standard TinyOS builds, but binary components do  
exist and are used by, e.g., Crossbow.

2) Linking objects that uses these shared types would need to make  
sure that both of them loaded the same set of extensions. Is there  
some way to detect that they don't?

3) Can you use them in nx_types? How would this work if you start  
exchanging packets, some of which have extensions and others don't?

You're talking about a fairly significant language change that could  
have a lot of complicated edge cases. As far as I can tell, there are  
two use cases for this, the first being packet metadata extensions  
and the second being shared data structures such as neighbor tables.  
While those are really fundamental to the level we're working at now,  
I'm not sure they're really the dominant problems: as David Moss  
pointed out, adding a few well-documented cpp options is not that big  
a deal.

I also don't think it's impossible to do this with existing nesC  
functionality. For example, if we start to need more extensible data  
structures, you could possibly do them as in this strawman proposal:

enum {
   EXTEND_SIZE = uniqueCount("ExtendExample"),
};

typedef struct {
   nx_uint8_t extensions[EXTEND_SIZE];
} extensible_t;


extension 1: an int8_t RSSI

enum {
   RSSI_OFFSET = unique("ExtendExample"),
};

extension 2: a three-byte structure "foo"

typedef nx_struct {
   nx_uint8_t a;
   nx_uint16_t b;
} foo_t

enum {
   FOO_OFFSET = unique("ExtendExample"),
   FOO_1 = unique("ExtendExample"),
   FOO_2 = unique("ExtendExample"),
};


To get an extension:


foo_t* getFoo(extensible_t* et) {
   return (foo_t*)(et->data + FOO_OFFSET);
}

To copy-in an extension:

void getFoo(extensible_t* et, foo_t* ptr) {
   memcpy(ptr, et->data + FOO_OFFSET, sizeof(foo_t));
}

I agree that this is not as clean as "extends," but it also doesn't  
require new language syntax.

Phil