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" <ludwig.ortmann@fu-berlin.de> To: "RIOT OS kernel developers" <devel@riot-os.org> Sent: Wednesday, April 24, 2013 6:21:26 PM Subject: Re: [riot-devel] Recommendations for Porting RIOT (Ludwig
Ortmann)
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
resolved.