[riot-devel] ns3 question about global variable in RIOT

Daniel Camara danielcamara at gmail.com
Fri Feb 28 11:15:13 CET 2014


Hi Emanuel,

  Don't get me wrong, I am not judging, complaining, or something like
that, just stating the fact that we have two VERY distinct clients here,
just that! Even though this obvious for me, it needs to be clear to all.
Well, I guess, even if the only clients were RIOT developers, it would
already worth the effort... not that cool, we could do better, but probably
would already pay the price.... and the ways to implement the adaptation
could be highly dependent on it.

 So yes I agree with you, we need to focus on hows, but I also partially
disagree because this specific point may impact the way the adaptation will
be made. If you decide the public is just the RIOT development team... and
you don't care for the second class of users (what is completely fair),
more "home made" and code dependent options could be considered.... , for
example, we wouldn't need something that is fairly independent of versions
of ns-3.  You could fix your code over, lets say,  version 19 and that is
it would be more than enough for you.

 Once more, don't get me wrong! Not judging, just trying to understand :).


On Fri, Feb 28, 2014 at 10:56 AM, Emmanuel Baccelli <
Emmanuel.Baccelli at inria.fr> wrote:

> Hi Daniel,
>
> Le 28 févr. 2014 09:59, "Daniel Camara" <danielcamara at gmail.com> a écrit :
>
> [...]
>
> >
> >>
> >> Of course, the results will be spoilt. But I don't know ns3 - if it's
> >> no big deal if it crashes that's fine with me as well. If it can cause
> >> damage (e.g. by corrupting files one might still want to have used
> >> afterwards) that might be an argument for separate processes.
> >>
> >   Ok Ludwig, there are two mind states that need to be clear and
> distinct one from the other. There is "yours", as RIOT developer that want
> to test your development and verify the behavior of RIOT over a more
> complex network setup. That is valid and, I guess, it is the why you, as
> community, would be interested in the adaptation. The second state of mind
> is the guy who wants to use this framework as a tool to test his own
> algorithms and theories. Some one that will use RIOT+ns-3 as as a medium to
> see other things, I am not interested in the tool itself it should be
> transparent to me. I mean, if the tool does not work correctly it is like
> you said to me... "Look I have this hammer here and you can use..... but it
> has some wholes on it!!!  So it will not work every time!".  I may use your
> hammer, if I have NO other tool... but just until I find a rock that is
> nearby :).
>
> We're on the same wavelength here, and I'm not sure it is worth discussing
> too much this question.
>
> While the core of RIOT is extremely stable, it's just that one cannot
> expect a whole OS + the bleeding edge of full network stacks under
> development to be as stable as a 1k lines of code implementing a simple
> network protocol on top of ns-3.
>
> For instance anybody testing Contiki+ some new networked application on
> ns-3 has realistically exactly the same concerns, which is inherent to this
> type of approach. If it made sense to port Contiki to ns-3 then it makes
> sense to port RIOT to ns-3. That's a simpler way to see it ;)
>
> So let's just do it and focus on the "how". Other questions are irrelevant
> in this context,  in my opinion.
>
> Does it make sense?
>
> Cheers,
>
> Emmanuel
>
> >
> >     Best regards...
> >
> >                      Daniel
>
> >
> > _______________________________________________
> > devel mailing list
> > devel at riot-os.org
> > http://lists.riot-os.org/mailman/listinfo/devel
> >
>
>
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
>


-- 
    Best regards...

                     Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20140228/465a7a98/attachment.html>


More information about the devel mailing list