Hello!

[Adam Lackorzynski]

Hi,

On Fri Feb 14, 2014 at 10:39:49 -0800, Blaine Garst wrote:
> 
> 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?

Overall, I think that current kernels do what's architecturally possible
regarding IPC. So I'd assume there's not much to squeeze out further.
And yes, it's not only about the good case but also for all the other
cases where more handling is needed and thus checks on the way. I'd
suggest to look at the existing kernels to see how they're doing.

> "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.

1st-gen kernels, i.e. Mach.

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

Fiasco/L4Re is also running on the Raspberry.




Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/