|
From: | Bahadir Balban |
Subject: | Re: Codezero v0.2 Capabilities |
Date: | Sun, 13 Dec 2009 13:48:00 +0200 |
User-agent: | Thunderbird 2.0.0.23 (X11/20090817) |
Michal Suchanek wrote:
2009/12/7 Bahadir Balban <address@hidden>: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 theThis 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
[Prev in Thread] | Current Thread | [Next in Thread] |