l4/sys/syscalls.h: No such file or directory

Adam Lackorzynski adam at os.inf.tu-dresden.de
Fri Sep 5 00:28:21 CEST 2014

On Wed Sep 03, 2014 at 15:20:31 +0200, Valentin Hauner wrote:
> On 09/03/2014 12:32 AM, Adam Lackorzynski wrote:
> > And indeed, you need to map the cap to the new task.
> >
> > l4_task_map(task_cap, L4RE_THIS_TASK_CAP,
> > l4_obj_fpage(l4re_env()->rm, 0, L4_FPAGE_RO),
> > l4_map_obj_control(l4re_env()->rm, L4_MAP_ITEM_MAP));
> Thanks, that works, there's no more kernel warning for an invalid pager now.
> But the actual thread function is not executed any more.
> Instead, Fiasco calls the deblock_refill method of my ready queue
> implementation for that thread (respectively Sched_context) _steadily_.
> I've attached the output of JDB's thread list. It's interesting to see
> that thread0 seems to wait for the first thread of task 1a.

Does it work with the default scheduler?

Thread 1b is the pager and they're both seem to be in an IPC. So likely
26 cause a page-fault and the page-fault is being resolved by sending an
IPC to the pager.

> The function of thread0 accesses its Edf_thread object created in task
> 1a (named 't'), so I've tried to map that object to the new task.
> Additionally, I've tried to map the thread capability for thread0
> ('t->cap') to the new task. But both approaches do not solve the problem.

It's likely a page-fault that happens because the address space of the
new task is empty and executing the first instruction of the thread
causes a page-fault on the code, that needs to be resolved by the pager.

Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/

More information about the l4-hackers mailing list