l4-hurd
[Top][All Lists]
Advanced

[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-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]