Ok, back to the topic:

On all platforms the LowPowerListening are exposed in ActiveMessageC,
except for

1) intelmote2, sam3u_ek and span, all of them are using CC2420, so I
have fixed this in their ActiveMessageC
2) eyesIFX: has Tda5250 radio chip, LowPowerListening is not implemented
3) tinynode: XE1205, has special LPL component and interface

So after this we can rely on LowPowerListeining being available, and I
will remove the PLATFORM_xxx ifdefs.

--------------

Whlile looking this issue, I came across the tosthreads library where
every single platform's ActiveMessageC is copied and updated to expose
the ReceiveDefault and SnoopDefault interfaces. I think we can expose
these interfaces in ActiveMessageC on most platforms (rfxlink radios
and cc2420 support this) and remove the duplicated ActiveMessageC
files.

--------------

Who is going to expose the LinkPacketMetadata interface? I am happy to
take pull requests.

Miklos

On Thu, Jan 24, 2013 at 6:55 AM, steve ayer <[email protected]> wrote:
> hi folks,
>
> i agree with miklos.
>
> as for breaking old platforms, that implies that applications cease to run
> on them due to development of core tos components.
>
> but if we want to follow the linux development model, then we must adhere to
> the principle that the "kernel" must under no circumstances break user
> space.
>
> the other thing to consider here is that platforms are largely a collection
> of chips, most of which live in -main/tos/, so once these implementations
> are stable, there should be little to cause an established platform to stop
> functioning properly and not too much actual platform code to carry.
>
> fwiw,
>
> steve
>
>
> On 01/23/2013 11:49 PM, Eric Decker wrote:
>>
>>
>>
>> On Wed, Jan 23, 2013 at 7:46 PM, Miklos Maroti <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>     Hi Eric,
>>
>>
>>     I think we should do the same as in linux development: we make
>>     reasonable effort to keep old platforms up to date, but if it turns
>>     out that one does not work any more, then either the users of the old
>>     platform has to make it work again, or we remove the platform. Old
>>     hardware can lie around and can become useful again for some tests,
>>     and so there is no point to preemptively remove old platforms before
>>     they are proven broken.
>>
>>     Miklos
>>
>>
>> I'm okay with that.  Less work.
>>
>> What do others think?
>>
>> Course there is the problem of how do you tell when something doesn't
>> work anymore if no one is actually trying to use something?
>>
>>
>>
>> --
>> Eric B. Decker
>> Senior (over 50 :-) Researcher
>>
>>
>>
>> _______________________________________________
>> Tinyos-devel mailing list
>> [email protected]
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>
>
_______________________________________________
Tinyos-devel mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel

Reply via email to