|Subject:||Re: Codezero v0.2 Capabilities|
|Date:||Mon, 07 Dec 2009 19:59:06 +0200|
|User-agent:||Thunderbird 188.8.131.52 (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.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
|[Prev in Thread]||Current Thread||[Next in Thread]|