l4-hackers June 2007

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

25 participants
27 discussions

l4 on mips
by Antoine Amirault 02 Jul '07

02 Jul '07

Hi, I'm student at ESIAL (a French engineering school) currently doing an internship in Beijing. I have to simulate l4 on a mips platform with qemu. I have downloaded pistachio and mips64-elf-3.4.4 from http://ertos.nicta.com.au/software/prebuilt/binaries.pml When i compile the kernel i obtain the following messages : antoine@liama-desktop:~/Desktop/pistachio-0.4-aos/build$ make make[1]: Entering directory `/home/antoine/Desktop/pistachio-0.4-aos/build' ===> src/glue/v4-mips64/asmsyms.cc cd src/glue/v4-mips64/ && /opt/nicta/tools/gcc-3.4.4-glibc-2.3.5/mips64-elf/bin/mips64-elf-gcc -nostdinc -I/home/antoine/Desktop/pistachio-0.4-aos/build/include -I/home/antoine/Desktop/pistachio-0.4-aos/kernel/include -I/opt/nicta/tools/gcc-3.4.4-glibc-2.3.5/mips64-elf/bin/../lib/gcc/mips64-elf/3.4.4/include -Umips64 -Uvr4181 -Uvr41xx -Uv4 -D__ARCH__=mips64 -D__CPU__=vr4181 -D__PLATFORM__=vr41xx -D__API__=v4 -imacros /home/antoine/Desktop/pistachio- 0.4-aos/build/config/config.h -imacros /home/antoine/Desktop/pistachio- 0.4-aos/kernel/include/macros.h -include /home/antoine/Desktop/pistachio- 0.4-aos/kernel/include/config.h -include /home/antoine/Desktop/pistachio- 0.4-aos/kernel/include/types.h -fno-builtin -fomit-frame-pointer -fno-exceptions -Wall -Wno-format -Wconversion -O3 -G 0 -mlong64 -mno-abicalls -non_shared -msplit-addresses -EL -mcpu=r4100 -mips3 -mabi=64 -Wa,-mabi=o64 -c /home/antoine/Desktop/pistachio-0.4-aos /kernel/src/glue/v4-mips64/asmsyms.cc cc1plus: error: invalid option `cpu=r4100' ===> src/api/v4/exregs.cc cd src/api/v4/ && /opt/nicta/tools/gcc-3.4.4-glibc-2.3.5/mips64-elf/bin/mips64-elf-gcc -nostdinc -I/home/antoine/Desktop/pistachio-0.4-aos/build/include -I/home/antoine/Desktop/pistachio-0.4-aos/kernel/include -I/opt/nicta/tools/gcc-3.4.4-glibc-2.3.5/mips64-elf/bin/../lib/gcc/mips64-elf/3.4.4/include -Umips64 -Uvr4181 -Uvr41xx -Uv4 -D__ARCH__=mips64 -D__CPU__=vr4181 -D__PLATFORM__=vr41xx -D__API__=v4 -imacros /home/antoine/Desktop/pistachio- 0.4-aos/build/config/config.h -imacros /home/antoine/Desktop/pistachio- 0.4-aos/kernel/include/macros.h -include /home/antoine/Desktop/pistachio- 0.4-aos/kernel/include/config.h -include /home/antoine/Desktop/pistachio- 0.4-aos/kernel/include/types.h -fno-builtin -fomit-frame-pointer -fno-exceptions -Wall -Wno-format -Wconversion -O3 -G 0 -mlong64 -mno-abicalls -non_shared -msplit-addresses -EL -mcpu=r4100 -mips3 -mabi=64 -Wa,-mabi=o64 -c /home/antoine/Desktop/pistachio-0.4-aos /kernel/src/api/v4/exregs.cc cc1plus: error: invalid option `cpu=r4100' make[1]: *** [src/api/v4/exregs.o] Error 1 make[1]: Leaving directory `/home/antoine/Desktop/pistachio-0.4-aos/build' make: *** [all] Error 2 Do you know how to solve this ? Maybe i should use another compiler. Thanks for your help Antoine

2 1

Fiasco@ARM - supported hardware
by Daniel Vandersee 01 Jul '07

01 Jul '07

Hello, how do you test L4 on an ARM platform? Do you have specific hardware for that purpose? You mentioned that you use ARM Integrator boards. As there are several integrator boards available: which one exactly do you use? Do you use other boards as well? I'm asking because I plan to buy an ARM board which is supported out of the box without the need to modify drivers. Do you additionally use software simulators to test L4? If so, which one do you use? I tried Skyeye to simulate an ARM integrator board as well as a SA1100-board but didn't get any output over the serial line. Qemu doesn't work either and terminates with the following error: "qemu: uncaught target signal 11 (Segmentation fault) - exiting". Kind regards, Daniel

2 5

Installing Generated Header Files
by Neal H. Walfield 01 Jul '07

01 Jul '07

Hi, I'm using BID and generating header files at compile time. I looked at the include role, however, as far as I can tell, it only installs files from the source tree, not from the object tree. The attached patch improves the include role-file to allow this mode of operation. The patch consists of two changes. First, before listing the directory, we change to $(INCSRC_DIR). (This also requires evaluating TARGET_CMD lazily, i.e., using a recursive variable, not a simple one, as INCSRC_DIR may be set later.) Second, an additional target has been added, headers, which can depend on generated header files. I also updated the documentation. The current patch doesn't allow installing header files from both the source directory and the object directory. This might be useful, however, it appears to require modifying the perl code, which I have done my best to forget. Thanks, Neal Index: mk/include.mk =================================================================== --- mk/include.mk (revision 74) +++ mk/include.mk (working copy) @@ -27,9 +27,9 @@ ifeq ($(origin TARGET),undefined) # use POSIX -print here -TARGET_CMD := find . -name '*.[ih]' -print +TARGET_CMD = (cd $(INCSRC_DIR); find . -name '*.[ih]' -print) else -TARGET_CMD := echo $(TARGET) +TARGET_CMD = echo $(TARGET) endif INSTALL_INC_PREFIX ?= l4/$(PKGNAME) INCSRC_DIR ?= $(SRC_DIR) @@ -64,7 +64,9 @@ } \ }' -all:: +headers:: + +all:: headers @$(TARGET_CMD) | $(call installscript,1) install:: Index: doc/bid-spec/spec.tex =================================================================== --- doc/bid-spec/spec.tex (revision 73) +++ doc/bid-spec/spec.tex (working copy) @@ -2274,22 +2274,32 @@ \subsubsection{Purpose} -The purpose of the include role is to install the local include-files -into the local install-tree or into the drops install-tree. The -role-file achieves two goals when managing include-files: +The purpose of the include role is to install all .h and .i under +INCSRC_DIR into the local install-tree or into the drops +install-tree. This role facilitates two goals with respect to managing +include-files: + \begin{enumerate} -\item The path where the include-files are to be found in is entirely +\item The path where the include-files are found is entirely defined by the package name and the target system of the include-files. -\item Once written, the makefile needs not to be modified, even if new - include files are added or old include files are removed from the package. +\item Once written, the make file need not be modified, even when new + include files are added or old include files are removed from the + package. \end{enumerate} The target system of an include file is determined by putting it into -a specific subdirectory. The role-file will install it accordingly -then. The following table defines the subdirectories depending on the -target systems. +a specific subdirectory. The role-file will then install it +accordingly. By default, INCSRC_DIR points is set to the source +directory. To install generated header files, set INCSRC_DIR to +§OBJ_DIR. There is currently no mechanism to exclude header files. +When generating header files, add them to the headers target (which +all depends on). + +The following table defines the subdirectories depending on the target +systems. + \begin{center} \begin{tabular}{|l|l|} \hline

2 1

memory overflow
by Antoine Amirault 29 Jun '07

29 Jun '07

Hi all! I'm trying to run l4 on qemu. I've successfully build the kernel and the user level code. I have followed the guide from l4ka : http://l4ka.org/projects/pistachio/ia32/gettingstarted.php and everything is running well except some little thing but i think it doesn't matter (like problem when unmounting,...). but whem i run qemu with qemu -fda fdimage.img, i got this message : Memory descriptor overflow (max=200, n=200) --- "KD# memdesc overflow" --- ---------------------------------------------9eip=f0102358, esp=f010ee400 --- then everything is locked> Do you know how i can solve that? Thanks. Antoine

1 0

How can Minix 3 be so small
by Hendrik Tews 27 Jun '07

27 Jun '07

Hi, I just noticed that the Minix 3 kernel is under 4000 lines. I couldn't easily find numbers for Pistachio, but I guess it is comparable to Fiasco, which is about 15.000 lines (without the kernel debugger). Could anybody explain why Fiasco is so big in comparison with Minix 3? From the difference in size I would expect that there is an essential difference in the feature set between Minix 3 and Fiasco. Or are the Minix lines just four times longer on average? Bye, Hendrik

8 8

RE: How can Minix 3 be so small
by Clermont, Nicolas 26 Jun '07

26 Jun '07

I have noticed that Minix3 only support one architecture (x86), and doesn't offers something like a HAL. Maybe this is one reason. -----Message d'origine----- De : l4-hackers-bounces(a)os.inf.tu-dresden.de [mailto:l4-hackers-bounces@os.inf.tu-dresden.de] De la part de Hendrik Tews Envoyé : mardi 26 juin 2007 17:13 À : l4-hackers(a)os.inf.tu-dresden.de Objet : How can Minix 3 be so small Hi, I just noticed that the Minix 3 kernel is under 4000 lines. I couldn't easily find numbers for Pistachio, but I guess it is comparable to Fiasco, which is about 15.000 lines (without the kernel debugger). Could anybody explain why Fiasco is so big in comparison with Minix 3? From the difference in size I would expect that there is an essential difference in the feature set between Minix 3 and Fiasco. Or are the Minix lines just four times longer on average? Bye, Hendrik _______________________________________________ l4-hackers mailing list l4-hackers(a)os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

1 0

clarification on explicit preemption points in Fiasco IPC
by Sergio Ruocco 26 Jun '07

26 Jun '07

Hi all, Forgive me if this is a silly question because it is documented somewhere, but I am unfamiliar with Fiasco source, and too in a hurry to go through all the Fiasco source code and cross-comare it with the documentation/papers/examples etc.... Skimming though Fiasco source code I checked out few weeks ago (the Doxygen online version is from 2005, out of date), I found 16 "Proc::preemption_point();" in the IPC path in the source file thread-ipc.cpp: [sergio 19:41 ~/Desktop/FIASCO/tudos/kernel/fiasco/src/kern]$ grep Proc::preemption_point thread-ipc.cpp | wc -l 16 Which tudos/kernel/fiasco/src/drivers/processor.cpp defines as: ... static inline void preemption_point() { sti(); irq_chance(); [ NOP NOP ] cli(); } ... My question is: As far as I know, Fiasco is entirely preemptable. Then why sprinkling the IPC path with Enable IRQs/NOP NOP/Disable IRQs ? Is there a document or a paper that discuss which parts of the kernel run with IRQs disabled / enabled ? Preemption disabled / enabled etc. ? Thanks in advance, Sergio -- Sergio Ruocco, PhD Research Fellow ruocco(a)disco.unimib.it / sergio.ruocco(a)gmail.com NOMADIS Lab. phone: +39-02-6448-7879 mobile, embedded real-time systems skype: 'sergioruocco' Università degli Studi di Milano-Bicocca, Italy

3 3

Re: 16-bit code and L4
by Valery V. Sedletski 25 Jun '07

25 Jun '07

On Mon, 25 Jun 2007 18:43:55 +1300 (MSD), Valery V. Sedletski wrote: >Yes, I see: > >L4_INLINE void >fiasco_gdt_set(void *desc, unsigned int size, > unsigned int entry_number_start, l4_threadid_t tid); > >It is privileged architecture-specific syscall, as I understood. And what means >"sanity checking" by the kernel? Does the kernel simply check that the descriptor >defines a valid segment, or, there are some additional chacks. For example, must >segments to be a non-overlapping, or not? (For 32-bit<-->16-bit thunking it is important >to have a possibility for the segments to be overlapping -- the code can be at the same >time to be in 16-bit segment and 32-bit segment). In segment.h header, there is an implementation of this function, through using LLDT instruction. (and not through using a special syscall). So, LLDT instruction is allowed for usermode programs, and the kernel intercept lldt instruction. -- Probably when this instruction is used in usermode program, the TRAP occurs, and the kernel handles this trap, modifying the LDT or GDT. Is this right? (I searched an fiasco_gdt_set() function in the source code and I found that L4Linux uses this function. So, it is, probably, was created for demands of L4Linux development?)

2 1

Re: 16-bit code and L4
by Valery V. Sedletski 25 Jun '07

25 Jun '07

> >I was working on allowing applications to use segmentation in >Pistachio as well. The modifications enabled apps to install segment >descriptors in a per address space LDT (after sanity checking by the >kernel of course). Modifying the GDT is not supported. > Is GDT modifying support planned in the future? > >By setting a thread in a special mode the kernel will never modify the >ES, FS, and GS of the thread. For optimization reasons the kernel >still retains the right to modify DS and SS though, so in effect these >can not be freely used by the app. Also, the kernel only allows data >segments to be installed --- no code or other segment types. > >It's been a while since I worked on this and got sidetracked by other >stuff, so I didn't completely finish the implementation yet. > > eSk > Is this documented somewhere? (It seems that it is not documented in L4 version X.2 API manual.) Maybe, it is in some source code documentation (Doxygen generated or alike)? > > > Thank you very much for your answer. WBR, Valery

1 0

Re: 16-bit code and L4
by Valery V. Sedletski 25 Jun '07

25 Jun '07

Thanks for answening so quickly. >> >Fiasco makes some GDT slots available to userland so that FS and GS can >> >be used with those. >> > >> >> And how to access these GDT descriptors from userland? Is this >> documented somewhere? Can usermode task change attributes of these >> descriptors (such as "16-bits" attribute)? Are they (descriptors) >> somehow mapped to requestor's address space or how else can usermode >> task modify these descriptors? Or, can usermode task only load >> selectors corresponding to these descriptors, but not modify >> descriptors itself? > >Userland can load descriptors that are sanity checked by the kernel and >then stored in the GDT. Using 16-bit segments should work too although I >never tried. Similar features are offered for the LDT. Our l4sys package >contains segment.h headers which describe the kernel interface. > Yes, I see: L4_INLINE void fiasco_gdt_set(void *desc, unsigned int size, unsigned int entry_number_start, l4_threadid_t tid); It is privileged architecture-specific syscall, as I understood. And what means "sanity checking" by the kernel? Does the kernel simply check that the descriptor defines a valid segment, or, there are some additional chacks. For example, must segments to be a non-overlapping, or not? (For 32-bit<-->16-bit thunking it is important to have a possibility for the segments to be overlapping -- the code can be at the same time to be in 16-bit segment and 32-bit segment). ... > >> And what about DS/ES? Can usermode task load these registers with >> another selector, as with FS/GS? > >Loading should work I guess but DS and ES are currently not restored on >exit to user. > so, if user restores these segments on exit, the loading should work? > > >Adam >-- >Adam adam(a)os.inf.tu-dresden.de > Lackorzynski http://os.inf.tu-dresden.de/~adam/ > > >

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 June 2007