l4-hackers March 2013

l4-hackers@os.inf.tu-dresden.de

17 participants
15 discussions

Error during the "ned" package build (svn revision 42)
by ggasnier31＠free.fr 16 Jul '13

16 Jul '13

Hello, I got the following error building the "ned" package for ARM architecture (Cortex-A9, Pandaboard). I use the last Linaro toolchain "gcc-linaro-arm-linux-gnueabihf-4.7-2012.12-20121214_linux". === Building package "ned" === make[1]: Entering directory `/home/repository/L4.kernel/fiasco/src/l4/pkg/ned' make[2]: Entering directory `/home/repository/L4.kernel/fiasco/src/l4/pkg/ned/server' make[3]: Entering directory `/home/repository/L4.kernel/fiasco/src/l4/pkg/ned/server/src' ... Building /home/repository/L4.kernel/fiasco/src/l4/ArmBuild/pkg/ned/server/src/.general.d make[3]: Leaving directory `/home/repository/L4.kernel/fiasco/src/l4/pkg/ned/server/src' make[3]: Entering directory `/home/repository/L4.kernel/fiasco/src/l4/pkg/ned/server/src' make[4]: Entering directory `/home/repository/L4.kernel/fiasco/src/l4/ArmBuild/pkg/ned/server/src/OBJ-arm_armv7a-l4f' ... Building .general.d ... Building Makefile.inc make[4]: Leaving directory `/home/repository/L4.kernel/fiasco/src/l4/ArmBuild/pkg/ned/server/src/OBJ-arm_armv7a-l4f' make[4]: Entering directory `/home/repository/L4.kernel/fiasco/src/l4/ArmBuild/pkg/ned/server/src/OBJ-arm_armv7a-l4f' make[4]: *** No rule to make target `ned.lua.bin.o', needed by `ned'. Stop. make[4]: Leaving directory `/home/repository/L4.kernel/fiasco/src/l4/ArmBuild/pkg/ned/server/src/OBJ-arm_armv7a-l4f' make[3]: *** [/home/repository/L4.kernel/fiasco/src/l4/ArmBuild/pkg/ned/server/src/OBJ-arm_armv7a-l4f] Error 2 make[3]: Leaving directory `/home/repository/L4.kernel/fiasco/src/l4/pkg/ned/server/src' make[2]: *** [src] Error 2 make[2]: Leaving directory `/home/repository/L4.kernel/fiasco/src/l4/pkg/ned/server' make[1]: *** [server] Error 2 make[1]: Leaving directory `/home/repository/L4.kernel/fiasco/src/l4/pkg/ned' make: *** [ned] Error 2 Commenting the line "OBJS += ned.lua.bin.o" in the file l4/pkg/ned/server/src/Makefile gives this error. ==> Linking ned lua.o: In function `lua(int, char const* const*)': /home/repository/L4.kernel/fiasco/src/l4/pkg/ned/server/src/lua.cc:97: undefined reference to `_binary_ned_lua_start' /home/repository/L4.kernel/fiasco/src/l4/pkg/ned/server/src/lua.cc:97: undefined reference to `_binary_ned_lua_end' make[4]: *** [ned] Error 1 make[4]: Leaving directory `/home/repository/L4.kernel/fiasco/src/l4/ArmBuild/pkg/ned/server/src/OBJ-arm_armv7a-l4f' make[3]: *** [/home/repository/L4.kernel/fiasco/src/l4/ArmBuild/pkg/ned/server/src/OBJ-arm_armv7a-l4f] Error 2 make[3]: Leaving directory `/home/repository/L4.kernel/fiasco/src/l4/pkg/ned/server/src' make[2]: *** [src] Error 2 make[2]: Leaving directory `/home/repository/L4.kernel/fiasco/src/l4/pkg/ned/server' make[1]: *** [server] Error 2 make[1]: Leaving directory `/home/repository/L4.kernel/fiasco/src/l4/pkg/ned' make: *** [ned] Error 2 Regards, Guillaume GASNIER

3 3

Question regarding the "Jdb::handle_user_request()' function
by Christian Prochaska 11 May '13

11 May '13

Hello, the 'Jdb::enter_jdb()' function in file 'jdb.cpp' contains the following code: // check for int $3 user debugging interface if (foreach_cpu(&handle_user_request, true)) { close_debug_console(cpu); leave_trap_handler(cpu); return 0; } I'm not sure why in this case the second argument of 'foreach_cpu()' is true. I understand that it causes the result to be true only if the 'handle_user_request()' function returned true for every currently running CPU. But I found that this can be a problem when using the '-jdb_cmd=JS' kernel argument: if only one CPU is currently running, the result of 'foreach_cpu()' is true, but when two CPUs are currently running, the 'handle_user_request()' function returns true only for one CPU, which makes the end result false and causes the kernel to stop with the JDB prompt shown. Can somebody please explain? Christian

2 4

[Fiasco.OC] Desctruction of objects created by factory
by Sergey Grekhov 27 Mar '13

27 Mar '13

Hello, L4 hackers! I have a question about Fiasco.OC. I am a bit stuck in understanding of how objects created by factory are destroyed? For example, we have a call from user space l4_factory_create_thread(). It creates object in Fiasco (file fiasco/src/kernel/factory.cpp) and map it using call map() from fiasco/src/kernel/map_util.cpp. However, the procedure of destruction of created objects (tasks, threads, gates, irqs, vms) is not clear: it seems that there is some kind of the "garbage collector", but I can not figure out some important things. Particularly: 1) where is the code which essentially destroys created objects (call destructors)? 2) what conditions make "garbage collection" to start? 3) how "garbage collection" can be forced from user-space? As a use-case, I can propose the fork-bomb test from Genode framework: it creates lots of new Genode threads (thus, it makes a lot of new thread/gate/irq objects in Fiasco.OC). Thanks in advance for your answer. -- Best regards, Sergey Grekhov

2 1

Question regarding L4_err class usage in method commit_result.
by Sergey Grekhov 22 Mar '13

22 Mar '13

Hello, L4 experts! I have a question regarding method Kobject_iface::commit_result() in the code of Fiasco.OC. One can easily find in the code something similar to following: return commit_result(-L4_err::EPerm); And this call is very confusing: it looks like returning message tag with error, but in fact the error bit (0x8000) is not set. Moreover, some values from L4_err is intersection with enumeration L4_msg_tag::Protocol because of: 1) sign '-' used when commiting result; 2) place where both values are saved - bits 31...16 of the message tag. And, finally, there are lots of returns similar to mentioned one (return commit_result(-L4_err::EPerm)) and there are no _any_ code which checks presence of these errors in the tag. I am very confused about these strange values saved in L4_msg_tag and it appears to me that in these cases should be used method Kobject_iface::commit_error(). Can someone explain the logic behind returning values defined in class L4_err? -- Best regards, Sergey Grekhov

2 3

repomgr log
by Jack Andrews 19 Mar '13

19 Mar '13

hi, thanks for fiasco - it will be a lot of fun for me. first question: is my output of repomgr normal? (see below). it seems to be doing things more than once. $ svn cat http://svn.tudos.org/repos/oc/tudos/trunk/repomgr | perl - init http://svn.tudos.org/repos/oc/tudos fiasco l4re localdir: src Checked out revision 49. Creating ./kernel Updating 'kernel': A kernel Updated to revision 49. Creating ./kernel/fiasco Updating 'fiasco': A fiasco Updated to revision 49. Creating ./kernel Updating 'kernel': At revision 49. Creating ./kernel/fiasco Updating 'fiasco': At revision 49. Creating ./kernel Updating 'kernel': At revision 49. Creating ./kernel/fiasco Updating 'fiasco': At revision 49. Creating ./kernel Updating 'kernel': At revision 49. Creating ./kernel/fiasco Updating 'fiasco': At revision 49. Creating ./kernel Updating 'kernel': At revision 49. Creating ./kernel/fiasco [snip] thanks, jack

3 2

Merging sigma0 and roottask
by Norman Feske 19 Mar '13

19 Mar '13

Hello Fiasco.OC developers, hereby, I'd like to propose a slight architectural change regarding the roles of sigma0 and roottask in Fiasco.OC-based systems. During our work with using the kernel for Genode, we repeatedly encountered problems that were somehow related to sigma0, in particular the priority inversion problem we reported last year (http://os.inf.tu-dresden.de/pipermail/l4-hackers/2012/005348.html) and a recent issue related to inconsistencies of caching attributes on ARM, which led to subtle memory corruptions. Both problems were pretty hard to debug and took us a lot of time. Knowing about those issues, there are of course ways to deal with them. The priority inversion problem could be solved by assigning the highest priority to sigma0. The cache attribute problem can principally be dealt with by managing the cache flushing manually and making sure not to touch the wrong cache lines. But this remains to be a mine field. Because roottask has all memory mapped, dangling pointers may go unnoticed, yet produce unwanted caching effects. In our experience, these kinds of problems remain largely invisible until the system gets highly dynamic (e.g., if the role of RAM for DMA buffers or normal memory changes at runtime). But once they occur, they become a nuisance. Without sigma0, our life would have been easier. With no sigma0 thread, there wouldn't have been a priority inversion problem. And without the sigma0 protocol that is unaware of caching attributes, we could easily maintain the consistent use of those attributes among all processes including roottask. Besides hitting the issues mentioned above, we found that the use of sigma0 implies two further problems. First, because roottask can hand out memory not before obtaining it from sigma0, all physical memory must be mapped within roottask. So the virtual memory of roottask limits the amount of physical memory usable in the system. And second, because roottask must maintain all those mappings with maximum privileges, a bug in roottask can silently corrupt arbitrary memory. Motivated by these observations, I conducted the experiment to remove sigma0 from the picture and see where this would lead us. Kernel changes -------------- The (preliminary) patch of the kernel and bootstrap is actually pretty small: https://github.com/nfeske/foc/commit/7599e863c2feb07a34b891499982f4ffb58ff3… I kept the term "sigma0" in place to keep the patch simple. In the following, the terms "sigma0" and "roottask" always refer to the first user-land process started by the kernel. Originally, sigma0 was paged with one-to-one mappings by the kernel and would use the normal map operation with a sigma0-virtual address as source of the mapping. Here, the new solution differs in that all memory mappings originating from sigma0 are now directly coming from the physical address space. This requires one kernel-internal interface change concerning the 'Mem_space::v_fabricate_map' function. This function is used in two situations, map and unmap. When mapping, it is used to determine the physical frame for the virtual address specified as source for the mapping. For the new version of sigma0, this makes no sense because the source address does not refer to sigma0's virtual address space. When unmapping, however, this function is used to look up the physical frame for the virtual page to unmap. In this case, the argument refers to an actual sigma0-virtual address. Consequently, the function cannot accommodate both use cases. Therefore, I introduced a new 'v_fabricate_map_src' function that accompanies the 'v_fabricate' function. For all processes other than sigma0, both functions are doing the same thing. But for sigma0, the 'map_src' function interprets the address argument as a physical address. Because this function is used to determine the mapping source, I have used the suffix "_map_src". The second noteworthy change is the distinction between sigma0 threads with a pager and those without a pager. The original version of sigma0 had no notion of a pager. There was only a single thread, paged by the kernel. Now, if roottask is sigma0, there are several threads. Most of them can be paged by a local pager in roottask. To distinguish both cases, I needed to introduce an 'is_null' accessor.function to the 'Context_ptr' class. User-land changes ----------------- The implications to Genode's version of roottask (called core) are more substantial but in very positive ways: The initialization of core's allocators used to required an interplay between core and sigma0. Because there is no longer a need to have all memory mapped in core, we can simply drop this whole procedure and just use the memory descriptors provided by the KIP. After an initialization phase where core faults-in its own image and the KIP via the kernel, core drops its privileges by assigning a core-local pager to all core threads. So any invalid access gets detected right away. Browsing through the page table of core using the kernel debugger is like visiting a desert. In contrast to the original version, it has become easy to maintain an overview of the mappings within core. The revocation of memory mappings used to rely on the in-kernel mapping database. This won't work for core anymore because core does not maintain mappings for the memory handed out to other processes. Instead, core uses 'l4_task_unmap' to flush mappings from non-core processes as needed. This is similar to how Genode works on OKL4. Still, non-core processes may create further mappings, which are captured by the in-kernel mapping database. Current state and open questions -------------------------------- With the current state of the implementation, the complete software stack of Genode runs without sigma0. This includes L4Linux. So I am pretty confident that the removal of sigma0 from the system does not imply functional disadvantages. That said, there are a few remaining questions that I'd like to discuss. First, the sole use of 'l4_task_unmap' to remotely flush memory mappings in other processes means that we must no longer provide the option of granting memory mappings. Otherwise, a process that received a mapping from roottask could "steal" the physical memory by granting it to someone else. Roottask would not know about that, and an attempt to flush the mappings in the original receiver of the mapping would just target a hole in the address space. My question is: "Can we live without granting memory?" or the other way: "What is a known use case for granting memory?" Second, the new situation triggers some code paths in the kernel that were not used before. Apparently, the unmapping of memory from sigma0 was not considered. This is where I hit a few assertions in the kernel. Right now, I have just worked around these assertions by uncommenting the offending code in 'kernel/fiasco/src/kern/map_util.cpp'. I understand that this is just a stop-gap solution. Would you like to lend a helping hand to find out... "How to support unmap from sigma0 in a clean way?" I would like to avoid Genode from diverging too much from the semantics of the official Fiasco.OC kernel. Hence, I would appreciate your consideration: "Would you like to follow a similar path with L4Re?" That would be very nice. But even if this should not be the case, I would find your rationale behind sticking with sigma0 very valuable to know, e.g., for reconsidering my plan. Regards Norman -- Dr.-Ing. Norman Feske Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

3 5

how to config L4Linux and Fiasco to access TCP/IP
by Jian Liu 18 Mar '13

18 Mar '13

Dear all, I am wonder how to config Fiasco and L4Linux to access intnet from a termail/Firefox in the sytem. I know we can set ifconfig and use "wget" in Genode. But is there a such solution for Fiasco and L4Linux? Which version can work and how to config them, E.g. menu.lst? Thanks. Best, Jian LIU ---- email to: gjk.liu(a)gmail.com

2 1

how to compiler
by fiasco 17 Mar '13

17 Mar '13

Hi, I want to know whether the l4re and fiasco.oc have some practical application which is open source. I want to build some useful pkg application for demo. The example like "Hello, world" is too small.thanks.

3 2

How to compiler DROPS
by fiasco 11 Mar '13

11 Mar '13

Hi, Now, I learn how to compiler DROPS, but I can not get the manual book which could guide me to compiler the DROPS and boot it form cd rom. Could someone give me a help? The document I need is how to compiler DROPS, create iso image and boot it. The target compiler DROPS is listed: http://os.inf.tu-dresden.de/drops/download.html

2 1

boot image
by fiasco 11 Mar '13

11 Mar '13

Hi, I find that some webpage is deleted which is about how to compiler, create iso, boot the DROPS. Could someone give me some doc, thanks, The DROPS is listed below: http://demo.tudos.org/eng_download.html

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers March 2013