Recommendations for Porting RIOT (Ludwig Ortmann)

Hi Cédric,

thank you for the tip! I'm exploring a different approach at the moment though: It's possible to modify the program counter that is being used when returning from a signal handler in the signal handler. This is undocumented but works in at least Linux and OSX. If I'm not missing something concept-wise I'll have this working soon. It's just a little fiddly for me as I am not experienced with assembler.

From what I gather, using ptrace would amount to the same underlying

strategy (change PC on return to user space from signal handler), but add considerable overhead (double the number of system calls and processes), right?

Cheers, Ludwig

Cédric Adjih schrieb:

  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 From: "Ludwig Ortmann" <> To: "RIOT OS kernel developers" <> Sent: Wednesday, April 24, 2013 6:21:26 PM Subject: Re: [riot-devel] Recommendations for Porting RIOT (Ludwig


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.

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


Hi Ludwig,

  Indeed it is much more elegant and efficient to do it in the same process (through signal handlers) ; with ptrace there would be multiple system calls and multiple context switches to achieve the same results. Hopefully this will be ok to implement.

Regards, -- Cedric