Hi Takai,
I was already discussing RIOT ns-3 porting with Daniel Camara from INRIA. He proposed a Google Summer of Code project (1) for this task which I am going to apply for. At the moment I am working on porting RIOT as a UNIX process (the "native" cpu/board).
If you still want to know technical details, please say so.
Cheers, Ludwig
Hi, Actually I am applying for the same gsoc project. And yes, I'm looking for the technical details.
Best regards, Taqi
A porting guide is in the makes but not available as of now.
The architecture is relatively clear, though. There is a well defined set of functions one needs to implement. You could just look through the native port as it is pretty much bare bones and self contained at the moment. In fact I'd start with this as a base for the ns-3 port.
One major problem is delaying this project though: RIOT has a preemptive scheduler. As of now I haven't been able to find a way to realize this within a UNIX process. I thought I had with the help of ucontexts and signal handlers, but it appears that switching back to interrupted contexts is just not (reliably) possible. I'm currently looking for a different solution, but it could turn out that it's plainly impossible.
As for the ns-3 integration, I guess you are in a better position to judge that since you already did that for contiki. From what I discussed with Daniel I'd say it should be possible in a fashion similar to the contiki ns3 port if the scheduler issue is resolved. Again, just look at the interfaces, it's all there.
Cheers, Ludwig
Hello Ludwig,
Just jumping into the conversation, but: did you consider using ptrace as a work-around, if you cannot solve the preemptive scheduler issue ?
Conceptually, it won't be far from being a "virtual machine" (that's the approach of "User Mode Linux"), and not so elegant, but I guess with something like "python-ptrace" it might be hacked together pretty quickly ?
Regards, -- Cedric