On Friday 25. May 2018 10.51.48 Richard Braun wrote: > > I don't think the problems we've experienced with Mach would translate to > an L4 based port, because they were really related to the kernel interface, > which most L4 implementations don't even provide, such as object > capabilities (I think OKL4 is the only one to do this) and high level > virtual memory operations such as paging for anonymous memory. > > On a side note, I personally consider object capabilities a strong > requirement for a Hurd-like system.
Doesn't Fiasco.OC provide sufficient object capability support, or is the "OC" labelling not accurate according to certain criteria? (I can envisage people having differing ideas about capability systems.) "Object-oriented capability system - Unified universal mechanism for naming, authorization and communication control" http://l4re.org/fiasco/features.html Going a bit deeper... "Fiasco.OC kernel services are implemented in kernel objects. Tasks hold references to kernel objects in their respective "object space", which is a kernel-protected table. These references are called capabilities. Fiasco system calls are function invocations on kernel objects through the corresponding capabilities." http://l4re.org/doc/l4re_intro.html#fiasco_intro "As a matter of fact, a system designed solely based on capabilities, uses so- called 'local names', because each task can only access those objects made available to this task. Other objects are not visible to and accessible by the task." http://l4re.org/doc/l4re_concepts_naming.html From a practical perspective, and from my limited experience writing simple servers and configuring them, one uses the init program (Ned) to define capabilities and to assign them to programs. It shouldn't be possible to fake capabilities due to the design of the system. How capabilities are transferred and shared is another matter, and I suppose that this is where the real design effort begins. Paul
