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