We have not invested heavily in determining the most appropriate cspace layout
for the root task, as every system is different, and the ideal for one is not
necessarily the ideal for another.
A number of systems we have create a new cspace for the root task with the
layout most appropriate for the particular system, then copy the caps into the
new cspace, and then change the root cnode for the root task to adopt the new
layout.
We view the initial cspace layout as really the bootstrap layout.
- Kevin
-----Original Message-----
From: Devel [mailto:[email protected]] On Behalf Of Norman Feske
Sent: Wednesday, 5 November 2014 3:17 AM
To: devel
Subject: [seL4] Reasoning behind the root cnode's guard value
Hello,
the seL4 kernel constructs the root task's CNode (in kernel/boot.c) by using
the configurable number CONFIG_ROOT_CNODE_SIZE_BITS as size and a guard value
calculated as 32 - CONFIG_ROOT_CNODE_SIZE_BITS. I understand that it makes the
capability name space nicely linear. But on the hand, doesn't it impede the
number of kernel objects addressable by root task?
When using Genode's core as root task on seL4, I will need to maintain a large
number of capabilities to kernel objects, in particular one for each page
managed by the core process. Naturally. I would like to organize the root
task's capability namespace hierarchically, allocating CNodes depending on the
dynamic work load. As far as I understand, however, root task would have no way
to address slots within such additional CNodes because all address bits are
already consumed by the root CNode indices + guard. For example, how is root
task supposed to specify capabilities that are not contained in the root CNode
as "service" argument to functions like 'seL4_TCB_WriteRegisters'?
One way I see would be to move capabilities back and forth between the root
CNode and other CNodes using 'seL4_CNode_Copy', effectively using the root
CNode as a kind of CNode cache. But this solution seems overly complicated.
Another way would be to dimension CONFIG_ROOT_CNODE_SIZE_BITS pessimistically.
But introducing such an upper bound a-priory would somehow contradict with
seL4's otherwise nicely dynamic resource management.
Yet another way would be to let root task use a smaller guard value that leaves
enough bits available to be used for second-level or third-level CNodes. But
since that would require a change of the kernel code, I suspect that this
approach is not in line with right seL4 way.
Could you share the reasoning behind the guard-value calculation and help me to
get on the right track? Or would you consider a configurable guard value for
root task as a reasonable feature request?
Cheers
Norman
--
Dr.-Ing. Norman Feske
Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
_______________________________________________
Devel mailing list
[email protected]
https://sel4.systems/lists/listinfo/devel
________________________________
The information in this e-mail may be confidential and subject to legal
professional privilege and/or copyright. National ICT Australia Limited accepts
no liability for any damage caused by this email or its attachments.
_______________________________________________
Devel mailing list
[email protected]
https://sel4.systems/lists/listinfo/devel
