[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The idea of an own L4
From: |
ness |
Subject: |
The idea of an own L4 |
Date: |
Sun, 09 Oct 2005 15:17:38 +0200 |
User-agent: |
Mozilla Thunderbird 1.0.6 (X11/20050813) |
The idea of an own L4 came up in irc several times. This is one thing we
should really think about, IMHO. I did so (well, not very much for now):
_why?_
- the dresden/karlsruhe guys don't really care about what we need/assume
is needed
- the dresden/karlsruhe guys don't give us access to development sources
and we dunno when an upcoming L4 will be released (we even don't know
whether this would solve our problems)
_how?_
There are 2 ways: writing a new implementation or forking an existing
one. The first one is too much work, IMHO. So we could either fork
pistachio or fiasco. The first one seems to be more portable, easyer to
build and is already in use by us.
So in conclusion, it's maybye the best to fork pistachio. But there's a
problem:
_the license problem_
Pistachio is distributed under a 2 clause bsd license that is compatible
with the GPL, AFAIK. This means we can simply license new files under
the (L)GPL. This is not the nicest, but OK, IMHO.
_what?_
This is the section where my list is most incomplete/wrong, I guess. But
e.g. Neal said he had a reasonable idea of what was needed. And Jonathan
has a lot of experience related to cap stuff, so I guess he could help a
lot, too. So here's what I found:
stuff definitely needed (descending priority):
- capabilities with copy semantics
- a way to revoke passed caps. Jonathan mentioned that not every
copied cap should be revokable (except for revokable-copy had the same
preformance). Revokable-copy could be implemented by a cap server, but
I dunno how performance looked like
- a call like cmp/identify/whatever
- endpoints
cool things for the future (unordered, to be evaluated [good or not]):
- generalised spaces (e.g. for fpages, I/O-fpages, caps)
- as a result of this, map/grant/unmap/copy/cmp should be implemented
for all kinds of spaces entries (fpages,caps,...)
- all kinds of resources (e.g. threads) as space entries [=first class
objects] (thus beeing
mappable/grantable/unmappable/copyable/cmp'able). This meant there was
no need for privileged system calls any more
L4.sec introduces a generic kernel capability space with four rights
per entry. Maybye a separate space for every first class object was
better, maybye not
- external kernel memory management
One of the l4.sec ideas is to let the user provide memory needed by
operations. This was nice, but complicated, IMHO.
- removing the utcb
This is another l4.sec idea. I'm not sure whether this was
good/helpful.
--
-ness-