Hi Daniel,

that's right we doesn't pass the scheduler capability to any children.
This is an security issue, if you simply pass the kernel's scheduler
capability into each task, they could interfere with a global scheduling
strategy.

To circumvent this, there are two possibilities: One could put a virtual
scheduler object's capability into the designated
'L4_BASE_SCHEDULER_CAP' capability slot of each task. I guess this is
the L4re way of confining the scheduling facilities of tasks.
The more Genode-like way, that Norman already proposed to you, is to
extend the CPU-session interface, e.g. by an additional 'migrate' or
'affinity' method, so that the kernel's scheduler capability further
resides in core, and you can use a kernel-independent interface for
load-balancing on different CPU's or cores.

I would advise you against mapping the scheduler's capability from core
to its children, even when hacking up a prototype or example. It's
probably not easier than extending the cpu-session interface. To use the
scheduler for distributing threads on different cores you need in
addition to the scheduler's capability the capability of each thread you
like to migrate, but these also reside in the 'core' task only.

I've produced a small patch for you, that extends the cpu-session
interface (for the Fiasco.OC platform only) by a 'migrate' function,
which doesn't do any real work - it's just a skeleton.
Of course, we will also provide a kernel independent solution for SMP in
the future, but if you want to get hands on experience with SMP and
Genode/Fiasco.OC now, this might help you as a starting point.

with best regards
Stefan

On 03/19/2011 01:29 AM, Daniel Waddington wrote: