Hello, genode!
In Thread_base::start() function, there is a capability inserting part:
Cap_index *i = cap_map()->insert(state.id, state.cap); l4_utcb_tcr_u(state.utcb)->user[UTCB_TCR_BADGE] = (unsigned long) i; l4_utcb_tcr_u(state.utcb)->user[UTCB_TCR_THREAD_OBJ] = (addr_t)this;
in the above, *state.kcap* is the cap-selector in the Genode CORE (where Cpu_root is there). And, Thread_base::start() function tries to create the capability with the same value of state.kcap (it looks rather than delegating, uses direct value). My question here is that, "could it be possible that the state.kcap value is already taken by some other capability in the Genode application?"
Best regards, Jaeyong
Hi Jaeyong,
On 01/31/2013 09:06 AM, jaeyong yoo wrote:
Hello, genode!
In Thread_base::start() function, there is a capability inserting part:
Cap_index *i = cap_map()->insert(state.id, state.cap); l4_utcb_tcr_u(state.utcb)->user[UTCB_TCR_BADGE] = (unsigned
long) i; l4_utcb_tcr_u(state.utcb)->user[UTCB_TCR_THREAD_OBJ] = (addr_t)this;
in the above, /state.kcap/ is the cap-selector in the Genode CORE (where Cpu_root is there). And, Thread_base::start() function tries to create the capability with the same value of state.kcap (it looks rather than delegating, uses direct value). My question here is that, "could it be possible that the state.kcap value is already taken by some other capability in the Genode application?"
Your suspicion is comprehensible, but fortunately there is no such conflict. The capability space of each task respectively protection domain is split up. The first part is under control of core, the other one is for free use by the application. This is just a convention defined by Genode's port to Fiasco.OC. It's not determined by the kernel.
The area controlled by core contains all capabilities that are asynchronously mapped to the protection domain by core. These are: the task capability, and 3 private capabilities for each thread of the domain. One of these capabilities, which each thread owns, is a IPC gate capability that is associated with that thread. This capability lies within the state.kcap capability index of the task. It's not the capability index in core. Core only propagates this information via the cpu session.
The second area of the capability space, which is not under core's control, contains all capabilities, which are mapped synchronously via IPC.
I hope this completes your picture of Genode/Fiasco.OC' capability handling a bit.
Best regards Stefan
Best regards, Jaeyong
Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main