Re: Codezero v0.2 Capabilities

Tom Bachmann wrote:
>> - The user API has been purposefully simplified, i.e. the capabilities
>> are hidden as much as possible from the userspace. The average
>> programmer need to know as little as possible about capability design.
>> For example you don't pass a capid to a system call. You pass resource
>> ids directly, but they get cap-checked internally. Once you want to
>> manipulate resource allocation in the system, you then need to
>> manipulate (unavoidably) capabilities and need to know what's going
>> on at that level.
>>  
> 
> I don't think that is really useful. Exposing protected capabilities is 
> about the *only* thing a microkernel should do (imho. it also has to do 
> some resource management but this should be exposed by capabilities as 
> well). Moreover, there is no need to try to write a user interface to 
> the kernel for "average programmers" because any decent system will wrap 
> kernel calls in some fashion or another anyway.
> 
> Furthermore, if you actually *can* design the user interface with these 
> reasions in mind something very strange is going on. I wouldn't claim to 
> be an expert, but both from my own experience and from what I have read 
> coming up with *any* kernel interface that works (i.e. that both can be 
> used to do what you want and can be implemented efficiently) is such a 
> daunting task that "usability" (as in, "for average programmers") is 
> really one of the first things you will push to userspace.
> 
> Thanks,
> Tom

This is an impression that I expected. It is not like the kernel has a 
translation layer. It is designed that way. Let's say on one end of the 
spectrum, there is a capability-based kernel with only an Invoke system 
call and it only accepts capids. On the other end, there is an L4 API 
with heterogeneous system calls that don't have any capability checking. 
Codezero has a hybrid design where the L4 API is retained, but 
implicitly checked for capabilities.

Let me give an example. If a thread has a capability to send an ipc 
message to another thread, this is described by a capability with a 
unique capid, and the whole capability structure may be read into 
userspace for discovering its details. It is normally kept inside the 
kernel in the capability list for the owner thread.

When it comes to making the ipc call though, you don't pass the 
capability id to the call. You pass the thread id you want to ipc to. 
The system call signature is the same as if capabilities were not there 
at all. But it surely gets checked, the relevant capability is found, 
it's resource id is matched with the passed thread id, and resolved.

The reason I did it this way is that, when I wanted to do ipc, it feels 
natural to pass the thread id. You might argue that the capability id 
could have been the same as the thread id, well in this way I managed to 
differentiate concepts from each other, and it felt that a user of the 
interface also benefits by not having to know about capabilities at all 
(provided that they're initially configured correctly of course).


-- 
Bahadir Balban