[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reviewing Hurd-on-L4 (and considering its future?)
From: |
Paul Boddie |
Subject: |
Re: Reviewing Hurd-on-L4 (and considering its future?) |
Date: |
Fri, 25 May 2018 14:49:00 +0200 |
User-agent: |
KMail/1.13.7 (Linux/3.2.0-6-486; KDE/4.8.4; i686; ; ) |
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
- Re: Re: Re: Reviewing Hurd-on-L4 (and considering its future?), (continued)
- Re: Re: Re: Reviewing Hurd-on-L4 (and considering its future?), William ML Leslie, 2018/05/25
- Re: Reviewing Hurd-on-L4 (and considering its future?), Nala Ginrut, 2018/05/29
- Re: Reviewing Hurd-on-L4 (and considering its future?), William ML Leslie, 2018/05/29
- Re: Reviewing Hurd-on-L4 (and considering its future?), Paul Boddie, 2018/05/29
- Re: Reviewing Hurd-on-L4 (and considering its future?), arnuld, 2018/05/30
- Re: Aw: Re: Reviewing Hurd-on-L4 (and considering its future?), Paul Boddie, 2018/05/24
- Message not available
- Re: Reviewing Hurd-on-L4 (and considering its future?), Rick C. Hodgin, 2018/05/24
Re: Reviewing Hurd-on-L4 (and considering its future?), Richard Braun, 2018/05/24