[Tinyos-devel] should this have an ifdef packet_link around it?

Miklos Maroti mmaroti at math.u-szeged.hu
Thu Feb 2 18:52:26 PST 2012


Hi Eric,

So you do not have a good solution either: 1) #ifdef throughout the
code is ugly, 2) warning if packet link is disabled/enabled is noisy,
3) silently use dummy packet link is confusing for many people.

Maybe just having the "not connected" is not such a bad idea, no?

Miklos

On Fri, Feb 3, 2012 at 3:00 AM, Eric Decker <cire831 at gmail.com> wrote:
>
>
> On Thu, Feb 2, 2012 at 3:55 PM, Miklos Maroti <mmaroti at math.u-szeged.hu>
> wrote:
>>
>> Hi Eric,
>>
>> Good observation. However, I am not sure what is the best way to
>> handle a missing feature. If I silently implement a dummy packet link
>> interface, then people might start wondering why it does not work! I
>> know that CC2420 does this, but is this really the best option?
>
>
> I would postulate that the wrong way to handle it is via a compiler error
> that says
> "no match".   At least without a good section in the FAQs (which do need to
> be
> updated one of these days) describing what that means.
>
> I do know of the newbies that is a very confusing thing and the frustrating
> part
> is where does one start to figure out what is broken.
>
> I realize that given the essence of nesC, and wiring and all, that "no
> match" is
> one of the basic errors.
>
>
>
> One choice is to propagate the  #ifdef/#endif to where the optional feature
> is
> used.   This is ugly.
>
> The other option is to have a null default module, possibly with a warning
> that
> says it is being used.   Course that would potentially be noisy which is
> also
> ugly and tends to encourage folks to ignore warnings.   Which is also a bad
> thing.
>
>> By the way, this error should not have happened. In the RadioConfig.h
>> I have some define magic that PACKET_LINK is always enabled when
>> people use the Ieee154MessageC. How did you compile your app to get
>> the error?
>
>
> Not my thing.   I was looking at something that I thought came in via
> tinyos-help.
> But I tried to find the thread again and couldn't find it.   So I don't know
> where this
> came from (old person thing).
>
> It was something having to do with implementing a new platform or some such.
>
> Given we can't really find it again.   I'd say don't worry about it til it
> comes up again.
>
>
>>
>>
>> Best,
>> Miklos
>>
>> On Mon, Jan 30, 2012 at 9:32 PM, Eric Decker <cire831 at gmail.com> wrote:
>> > I've taken a look recently at a wiring problem with
>> > tos/chips/rf230/RF230Ieee154MessageC.nc and noticed:
>> >
>> > 87: PacketLink = RF230RadioC;
>> >
>> > But tos/chips/rf230/RF230RadioC.nc looks like...
>> >
>> > provides {
>> >     ...
>> > #ifdef PACKET_LINK
>> >       interface PacketLink;
>> > #endif
>> >    ...
>> > }
>> >
>> > I would think that RF230Ieee154MessageC.nc should also have the #ifdef
>> > packet_link.
>> >
>> >
>> > This comes up because if PACKET_LINK isn't defined, strange errors are
>> > generated which are difficult for folks to figure out where to look to
>> > fix
>> > it...
>> >
>> >
>> >
>> > Which of course gets ugly.
>> >
>> > Why not have a null PacketLink that gets wired in as the default and get
>> > replaced by useful code if needed?
>> >
>> > eric
>> >
>> >
>> > --
>> > Eric B. Decker
>> > Senior (over 50 :-) Researcher
>> >
>> >
>
>
>
>
> --
> Eric B. Decker
> Senior (over 50 :-) Researcher
>
>



More information about the Tinyos-devel mailing list