Re: The idea of an own L4

[Leonardo Lopes Pereira]

I think that we do not need to create a own L4, we can create something like a 
branch of L4 Pistachio, adding features to it, but keeping the same "base" of 
Pistachio, appling their patches. All that we will do is add those new features 
that are necessary to us.

On Sun, 09 Oct 2005 15:17:38 +0200
ness <address@hidden> wrote:

> 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-
> 
> 
> _______________________________________________
> L4-hurd mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/l4-hurd

-- 
leonardolopespereira at gmail.com

GNU Privacy Guard (GPG)
ID da chave: 83E8AFBF | servidor: keys.indymedia.org
gpg --keyserver keys.indymedia.org --recv-keys 83E8AFBF

pgpC3gzvFNcoK.pgp
Description: PGP signature