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
