Michal Suchanek wrote:
2009/12/7 Bahadir Balban <[email protected]>:
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
This is imho the wrong thing to do and it is also a failure of some
(incomplete) Viengoos system manual I read. By allowing the user to
inspect the capability you remove transparency and make things like
virtualization and capability proxies impossible to do without
cooperation of the processes that run in the virtualized environment.
If you instead make capabilities opaque handles that can be used to
invoke a service but can't be used in any other way you make proxies
and virtualization transparent adding to the extensibility and
modularity of your system. Of course, you better remember what
capability implements what interface when storing them or design a
call that identifies the interface implemented by a capability.
Thanks
Michal
This is a good point. But the current set of capabilities I implemented
are rather rigid in their definition. The kernel strictly defines the
resources that it manages, and those capabilities are not really open
for different implementations. I think I would prefer to keep the kernel
interfaces to have well-defined behavior so this would not be a relevant
requirement from a kernel interface point of view.
As a next step though, it might be a good experiment to see if userspace
processes can provide their own user buffers to install custom
capabilities. The kernel, then would not care about the capability
details, only check them on behalf of the owner. Such user-defined
capabilities could be invoked with an opaque, user-defined capability
invocation protocol over the ipc call.
This would be closer to your suggestion I think, but it is not something
I can spend time on. I would be willing to help if someone was
interested to do it though.
--
Bahadir Balban
