[ludwig.ortmann@fu-berlin.de: [riot-devel] Native RIOT preview]

Dear riot-users and developers,

we are glad to announce that it is now possible to have a first look at RIOT without the need to access to supported hardware!

Let's start the RIOT! Oleg

Great! Emmanuel

Congratulations for this great achievement!

BTW do you think this could be a first step towards a simulation of RIOT? Because, Monday I will meet ns3 guys, our collegues in Sophia, they will present how they are integrating ns3 and Contiki - so if you are interested, would some specific information be useful for you ?

Best regards, -- Cedric

Hi,

I have no experience whatsoever with ns3, but as far as I understand it: yes and yes.

Off the top of my head: The biggest difference between RIOT and Contiki with regard to interfacing with a simulator is that RIOT has preemptive context switches. This will probably lead to a higher overhead when synchronizing with an external (from the OSs view) clock.

Interesting questions: - are they running the whole Contiki system or just parts? - how does ns3 communicate time / how are they handling time? - at what level (driver/hardware/syscall) do they intercept io?

Most interesting of course would be their diff and/or pointers to helpful sources of information.

Thank you for your offer!

Cheers, Ludwig

Cedric Adjih schrieb:

Hello Ludwig, hello Rioters,

  For this possible ns3 integration topic, thank to Daniel Camara [in copy], I understood the following:

- for the Contiki <-> ns3 integration, the architecture of Contiki   itself will be used. ns3 will appear as a new architecture for Contiki,   and low-level parts (drivers, timers) will be rewritten like any   Contiki port.   So, to answer the question it will be "just parts" of the Contiki system,   except that the parts could be pretty big, and more importantly, Contiki   is itself naturally divided in parts.   I think that the missing point prior actual implementation is how to   handle Contiki global variables in such an architecture.

- For a possible RIOT port to ns3, Daniel advice is that such a method   of integration would be more elegant and more straightforward.

- Also another possibility that was pointed is the DCE module in ns3:   the intent of DCE (Direct Code Execution     http://www.nsnam.org/~thehajime/ns-3-dce-next-doc/doc/build/html/index.html)   is exactly to integrate external programs in ns3 without modifying the source.   From what I gathered, it works with clever tricks in the dynamic library loader, etc.   Several instances of the same program are run from ns3, by having their   memory mapped at different absolute addresses. Moreover normal (e.g. POSIX)   system/library calls are mapped to ns3 operations by hijacking the library   function calls (normally defined in dynamic libraries, external to the program).   This uses Position Independent Executables     http://en.wikipedia.org/wiki/Position-independent_code   Daniel opinion is that using DCE with Riot-Linux-port, could either work   directly, or could fail with a difficult-to-solve (conceptual) problem.

Best Regards, -- Cedric