understanding l4re

[Björn Döbel]

Hi,

On 14.05.2012 18:13, Ryan Brown wrote:
> Thank you for your answers, they were very helpful. Now I have some more
> questions:
>
> Are any of these documents relevant to, or helpful in working with
> Fiasco.OC? http://l4hq.org/docs/manuals/

No. These docs don't describe the Fiasco.OC API (although many of the 
concepts are shared). The relevant documentation for Fiasco and the L4 
Runtime Environment is at https://os.inf.tu-dresden.de/L4Re/doc/

(yes, that's all for now - if you have any questions, please ask and 
we're glad to help). There's also a Wiki: http://wiki.tudos.org/Main_Page

> Is there a limit on how many threads you can create with pthreads?

As in any other system, pthread_create() returns -EAGAIN if there are 
insufficient system resources to create another thread. This may happen, 
if the lib is not able to allocate a stack or TLS area for the thread or 
in the Fiasco.OC case if there are insufficient kernel resources.

> How does thread scheduling work? As a policy this should be implemented
> in user space, right?

Actually, scheduling is the only policy that is implemented in the 
kernel and as far as I know most L4 variants do this, although there 
have been experiments to do it in user space. [1]

> Does pthreads take care of this? I see that it
> handles resuming the highest priority waiting thread for example when
> unlocking a mutex. But what if more threads are runnable than the number
> of cores?

Fiasco.OC schedules threads based on their priorities. (Same priority 
leads to round-robbin scheduling.) There are separate run queues for 
every physical CPU and you have to explicitly bind a thread to a 
physical core.

> Are shared libraries supported?

Yes. There is a port of ldso in l4/pkg, most libs are built as shared 
variants as well. There's even an example for starting a version of the 
hello example with shared libraries:

* First check out L4Re as documented on the web page.
* Then go to l4/pkg and do
   $> svn up examples/
* Then build examples/misc/shared-hello
* In l4/conf/modules.list there is an example entry "hello-shared" that
   should get you set up.

> Actually, I think I saw that fork/exec, etc were stubs.

These may be stubs in the C library, but there are no implementations of 
fork/exec for L4Re. (Although, this would be possible.)

> I believe I've seen L4 apis for creating new address
> spaces, but what about loading an executable into the address space?

This is done by an ELF loader. The default loaders are moe (for the 
first binary) and ned (the Lua-based init program). You can also write 
your own and use the functionality provided by l4/pkg/libloader.

 > I suppose I should take more of a look at moe and ned to understand this.

Indeed. ;)

> How does the L4re logger get initialized and connected to the serial
> console?

When being started, an L4Re application gets an initial set of 
capabilities (== communication channels). These are the initially 
available services and one of them is the Log channel which by default 
provides stdout and stderr for your application. The default log 
implementation is provided by the kernel who has a serial console driver 
built in (debugging...).

> I see some code inside bootstrap for initializing the uart, is
> this where it happens?

This is the first place where this happens. Bootstrap is a bit weirdly 
placed in l4/pkg. Actually, it is the "kernel" that is initially booted 
for every L4 setup. It sets up a multiboot environment and then hands 
over control to Fiasco, which then is the real kernel to run. As the 
Fiasco codebase is separate from the L4Re code base, you'll find another 
UART driver in Fiasco as well. Yep, that's redundant.

> Thanks for the help, and sorry for so many questions.

No worries. May I ask if you have any special project in mind?

Cheers,
Bjoern


[1] J. Stoess: Towards Effective User-Controlled Scheduling for 
Microkernel-Based Systems, SIGOPS OSR, July 2007