[riot-devel] Recommendations for Porting RIOT (Ludwig Ortmann)

Ludwig Ortmann ludwig.ortmann at fu-berlin.de
Thu May 2 12:36:55 CEST 2013


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
> ----- Original Message -----
> From: "Ludwig Ortmann" <ludwig.ortmann at fu-berlin.de>
> To: "RIOT OS kernel developers" <devel at riot-os.org>
> Sent: Wednesday, April 24, 2013 6:21:26 PM
> Subject: Re: [riot-devel] Recommendations for Porting RIOT (Ludwig
Ortmann)
> On 04/24/2013 02:04 PM, tkennouc at inria.fr wrote:
>>> 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.
> Again, just look at the interfaces, it's all there.
> Cheers, Ludwig
> _______________________________________________
> 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








More information about the devel mailing list