Base capabilities

Stefan Kalkowski stefan.kalkowski at ...1...
Tue Mar 22 09:48:11 CET 2011

Hi Daniel,

a Platform_thread encapsulates all platform-specific properties of a
thread, as well as platform-specific operations upon it. There are
Platform_thread definitions for all platforms, Genode currently supports
like Linux, Okl4, Nova, Fiasco.OC etc..

Every time you create a thread via a CPU-session, core creates a
Platform_thread object representing the actual Kernel object.

In contrast to Platform_thread, the Cpu-session implementation is highly
generic and for all different platforms identically.

I hope this clarifies your question.


On 03/21/2011 09:38 PM, Daniel Waddington wrote:
> Stefan,
> To help with my understanding, what exactly is a Platform_thread?  How
> does it tie in?
> Thanks
> Daniel
> On 03/21/2011 04:03 AM, Stefan Kalkowski wrote:
>> 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:
>>> Hi,
>>> I'm trying to put in some temporary feature in Genode to set the
>>> affinity of threads.  In Genode the scheduler capability
>>> (L4_BASE_SCHEDULER_CAP) doesn't seem to be passed from the core to the
>>> children.  Is there any obvious way to do this with the existing Genode
>>> implementation - we can hack up a solution but I wanted to check first.
>>> Thanks
>>> Daniel
>>> ------------------------------------------------------------------------------
>>> Colocation vs. Managed Hosting
>>> A question and answer guide to determining the best fit
>>> for your organization - today and in the future.
>>> _______________________________________________
>>> Genode-main mailing list
>>> Genode-main at
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> _______________________________________________
>> Genode-main mailing list
>> Genode-main at
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software 
> be a part of the solution? Download the Intel(R) Manageability Checker 
> today!
> _______________________________________________
> Genode-main mailing list
> Genode-main at

Stefan Kalkowski
Genode Labs ·

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the users mailing list