doebel at os.inf.tu-dresden.de
Tue May 15 00:02:08 CEST 2012
On 14.05.2012 18:13, Ryan Brown wrote:
> Thank you for your answers, they were very helpful. Now I have some more
> 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. 
> 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
> 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.
> How does the L4re logger get initialized and connected to the serial
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?
 J. Stoess: Towards Effective User-Controlled Scheduling for
Microkernel-Based Systems, SIGOPS OSR, July 2007
More information about the l4-hackers