Hello!

[Blaine Garst]

On Feb 14, 2014, at 4:44 AM, Julian Stecklina <jsteckli at os.inf.tu-dresden.de> wrote:

> On 02/14/2014 07:10 AM, Blaine Garst wrote:
>> I am looking for a non-GPL kernel/executive/nano-kernel [...]
> 
> Is there any specific reason why you would shy away from GPL code? The
> only non-GPL L4 kernel I can think of is Pistachio:
> 
> http://www.l4ka.org/65.php

Yes, thank you, now it is clear why there wasn’t a single consistent license reference.

My interest in non-GPL is that, if successful, my explorations will be released and supported under yet another licensing arrangement for free personal non-monetary uses in some higher level software I’m cooking, and then possibly some licensing revenue generating for-profit spinoffs etc., such that GPL could not be used.  Re-exporting changes under “dual BSD” would also be the friendly thing to do.

At first glance I suspect that my architectural work will improve L4 IPC times.

The premise is/was that threads don’t belong to address spaces but instead wander with the IPC from one address domain to another carrying their arguments in registers.  IPC is a trap, adjust mmu, proceed.  If the IPC is carrying an IPC end-point, e.g. a capability, its a different trap and some bookkeeping must be done, but it can also be blindingly fast.  The hard question is and was, well, if you don’t have a blocking thread waiting for the IPC, how do you manage all these spontaneous “up-calls”.

My answer is found in my Actor Runtime.

But what about my suspicion?  Seems like “swap thread registers system call” will alone be more expensive in both time (I avoid the need to do so) and space (since there are no nano-kernel threads waiting for activation).  Anybody have my same hunch?

> 
> It works, but is not actively maintained anymore. If you need a userland
> for Pistachio, you can try Genode: http://genode.org/
> 
>> Is this an appropriate list to discuss whether L4 is an appropriate starting point and such issues that might arise from my exploration?
> 
> Sure!

Okay, some deeper thoughts.

"After disastrous results in the early 90's, the microkernel approach now seems to be promising, although it still bears a lot of research risks.”

I’m curious as to what “results” were being referenced.  I shifted out of kernel work around 1992 (after co-architecting the maxi kernel to end all maxi-kernels, SVR4, and being forced to abandon the nano-kernel that would have made it all better!).

At this point I can easily persuade people that the existing maxi-kernel notions of Threads are completely off-base - these were extended simulations of “multi-core” that unified and extended the fundamental notion of simulated “multi-processors” that is the basis for time-sharing by way of kernel timer-interrupts.  Well, now we have multi-core for real but there is also fairly widespread agreement that we computer scientists and engineers have been caught flat-footed (to a large degree by Intel’s multi-decade just-make-one-core-faster marathon).

So I think its time yet again (for others) to re-think these notions, and I have some experience and ideas on the subject.  I’m not keen on preaching, I prefer to build and show and let people learn by exploring.

Not that its multicore (yet), but has anyone in this community been exploring putting L4 on a Raspberry Pi?

Blaine Garst
(former “Wizard of Runtimes”@Apple)







> 
> HTH
> Julian
> 
> 
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers