Using Fiasco L4re APIs

Daniel Waddington d.waddington at ...60...
Thu Mar 17 21:54:00 CET 2011


Hi Norman,

Yes, I got the L4 headers to work now.

>What if one program would create multiple CPU sessions and specify the
>CPU session for each thread as constructor argument of the 'Thread'
>class? In the extreme case, each thread could be created via a distinct
>CPU session using a different affinity. The program would express its
>desired affinity for each CPU session as session argument. The parent
>then has the option to change the affinity when forwarding the session
>request towards Genode's core. This would be a quite powerful mechanism
>to assign any subsystem to arbitrary sets of CPUs without letting the
>subsystem know about it.

Yes I think this would work.

Daniel


On 03/17/2011 11:42 AM, Norman Feske wrote:
> Hi Daniel,
>
>> As far as design choice, I think you need both.  When you can use an
>> affinity mask for a set of threads that belong to a single CPU session,
>> then setting this mask through the CPU session works.  However, lets say
>> you want to explicitly define each individual mapping of thread to
>> core.  In this case you either need to be able to define the affinity
>> from the thread, or some how build a map of threads-to-affinity in the
>> CPU session.  The latter could be cleaner, but less conventional.
> What if one program would create multiple CPU sessions and specify the
> CPU session for each thread as constructor argument of the 'Thread'
> class? In the extreme case, each thread could be created via a distinct
> CPU session using a different affinity. The program would express its
> desired affinity for each CPU session as session argument. The parent
> then has the option to change the affinity when forwarding the session
> request towards Genode's core. This would be a quite powerful mechanism
> to assign any subsystem to arbitrary sets of CPUs without letting the
> subsystem know about it.
>
> Currently, the 'Thread_base' implementation always uses the CPU session
> of 'Genode::env()->cpu_session()'. However, the replacement of this
> hard-wired policy by a construction argument would be a sensible way to
> enable the binding of threads to manually created CPU sessions.
>
>> I did try to include the l4sys headers in my genode program, but it sort
>> of blew up - it found the headers but not things like L4_PAGESHIFT.
> Normally, this shouldn't be a problem. Can you give the following
> program a try?
>
> base-foc/src/test/headers/test.cc:
>
>    namespace Fiasco {
>    #include<l4/sys/types.h>
>    }
>
>    #include<base/printf.h>
>
>    int main(int argc, char **argv)
>    {
>      using namespace Fiasco;
>
>      Genode::printf("L4_PAGESHIFT=%ld\n",
>                     (long)L4_PAGESHIFT);
>      return 0;
>    }
>
> base-foc/src/test/headers/target.mk:
>
>    TARGET = test-headers
>    SRC_CC = test.cc
>    LIBS   = env cxx
>
> base-foc/run/headers.run:
>
>    build "core init test/headers"
>    create_boot_directory
>
>    install_config {
>      <config>
>        <parent-provides>
>          <service name="ROM"/>
>          <service name="LOG"/>
>        </parent-provides>
>        <default-route>
>          <any-service>  <parent/>  </any-service>
>        </default-route>
>        <start name="test-headers">
>          <resource name="RAM" quantum="1M"/>
>        </start>
>      </config>
>    }
>
>    build_boot_image "core init test-headers"
>    append qemu_args "-nographic -m 64"
>    run_genode_until "exited with exit value 0" 20
>
> To execute the test, just issue 'make run/headers' from your build
> directory.
>
> Cheers
> Norman
>




More information about the users mailing list