[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Codezero v0.2 Capabilities

From: Bahadir Balban
Subject: Re: Codezero v0.2 Capabilities
Date: Mon, 07 Dec 2009 19:59:06 +0200
User-agent: Thunderbird (X11/20090817)

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]