Native_capability as [out] parameters

[Daniel Waddington]

Thanks Norman and Stefan for your help.  For the immediate need I will 
use alloc_irq together with the ICU cap limited to my special core 
process. If I need to get raw caps out again, I think I will look into 
using core's cap session or partitioning out the cap id space.

Daniel

On 02/20/2013 04:36 AM, Stefan Kalkowski wrote:
> On 02/20/2013 11:53 AM, Norman Feske wrote:
>> Hi Daniel,
>>
>>> OK, I think this clears things up for me - the hazards of Genode
>>> hacking! ;)
>> I am not quite sure what you mean by "hazard". The mechanism Stefan
>> described is actually a safety net that relieves the users of the
>> framework from the burden of managing the lifetime of capabilities
>> manually. I'd to say that doing the lifetime management of capabilities
>> manually would be hazardous. In contrast, the Genode API provides a
>> coherent and safe way that avoids leaking capabilities (and the
>> associated kernel resources).
>>
>> The problem you are facing right now is that you are deliberately
>> breaking through the abstraction of the API and thereby (unknowingly)
>> violate an invariant that is normally guaranteed by the Genode API
>> implementation. In particular, you create capabilities out of thin air,
>> which is not possible via the legitimate use of the API. Because this
>> invariant is not satisfied anymore, another part of the API (RPC
>> marshalling of capabilities) that relies on it does not work as expected.
>>
>> So I support Stefan with his suggestion of his first solution (letting
>> core create capabilities and export them via a core service) as this
>> solution will not work against the design of Genode.
>>
>> That said, there might be third solution, which is the creation of a
>> valid ID manually without involving core's CAP service. This is done for
>> constructing the parent capability at the process startup:
>>
>>
>> https://github.com/genodelabs/genode/blob/master/base-foc/src/platform/_main_parent_cap.h
>>
>> Following this procedure, a valid Genode capability gets created, which
>> can then principally be delegated via RPC. By using
>> 'cap_map()->insert()', the code satisfies the invariant needed by the
>> RPC mechanism to marshal the capability.
>>
>> This way, you could wrap a Fiasco.OC capability selector (e.g., a
>> scheduler cap selector) into a Genode capability in order to delegate it
>> to another process. I guess, this is what you'd like to do?
>>
>> @Stefan: Would that be a feasible approach?
> Well, not really. The parent capability is a corner case. It's the only
> capability that is inserted manually without usage of the IPC framework,
> because we need it to do the first IPC at all.
> To enable usage of the parent capability, when starting a new child, its
> parent stores the capability ID at a specific place (&_parent_cap), when
> setting up its address space.
> For all capabilities "created out of thin air" the problem remains to
> get a valid capability ID.
>
> A viable third way, without using core's CAP service, would be to shrink
> the ID range used by core, and use the IDs, which become free. Of
> course, the problem remains to divide up the IDs between potentially
> different tasks.h
>
> @Daniel: The burden of having global capability IDs, a capability
> registry, retrieval etc. wouldn't exist, if the kernel API would allow
> to identify capability duplicates when receiving one. Currently, the
> only way to identify, whether a received capability is already existent
> in the protection domain, is either to compare it against all
> capabilities one possesses, or by using an additional identifier. The
> first solution obviously is not feasible, because every comparison
> between two capabilities means one kernel syscall. That means, if you
> own 100 capabilities you've to do 100 syscalls when receiving a new
> capability. Therefore, we've chosen the second approach of using a
> globally unique ID that is sent in addition to the capability.
> A capability-based kernel, where this additional ID isn't needed
> anymore, is for example NOVA.
>
> Best regards
> Stefan
>
>> Cheers
>> Norman
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20130225/d1463760/attachment.html>