- l4-hackers - example.com Site

Problem with hybrid L4Linux task
by Mathias Krause 19 Sep '05

19 Sep '05

Hello Hackers, I've got a problem with a hybrid Linux Task. I want to create a little tool to tranfser data between two L4Linuxes easily. A tool similar to the famous netcat but using IPC instead of UDP/TCP. So far so good. Server is listen for client and client is sending data to the server (using long IPC transfering data as dwords). The problem is that the data doesn't arrive at the server task. There only an empty IPC message gets received (no IPC error). After I've played around a while with debug messages I got strange results. Using debug messages (simple printf()) inbetween and the transfer succedes! Digging a little deeper got me to the point that it must be a problem with the compiler. Using 'gcc -O0' generates working code too - 'gcc -O2' doesn't. Trying another compiler (gcc version 4.0.1 (Debian 4.0.1-2)) with -O2 got me also working code. So my question is if really my gcc (version 3.3.5 (Debian 1:3.3.5-13)) is broken or the includes under l4/l4sys/.../ipc.h. Maybe the inline assembly isn't that clean? But just a guess. My GNU assembly knowlegde isn't that good. Greets, Mathias PS: I'm runing Debian sarge over here.

2 4

Compiling DROPS' dietlibc on FreeBSD
by Julian Stecklina 15 Sep '05

15 Sep '05

Hello, after changing minimal parts of dietlibc's build procedure, I get as far as cd pkg/dietlibc ; gmake actually doing something but it fails with the following error: ... Compiling lib/__v_printf.o LD_PRELOAD=/home/blitz/src/l4/tool/gendep/libgendep.so GENDEP_TARGET=lib/__v_printf.o GENDEP_BINARY=cc1 gcc33 -c -nostdinc -DRAM_BASE=0x0 -DUSE_DIETLIBC=y -DSYSTEM_x86_686 -DARCH_x86 -DCPUTYPE_686 -DL4API_ -I../include -I.. -I../../../idl/OBJ-x86- -I/include -gstabs+ -g -O2 -fno-strict-aliasing -march=i686 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c -o lib/__v_printf.o /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:2:20: stdarg.h: No such file or directory In file included from /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:7: ../dietstdio.h:12:20: stdarg.h: No such file or directory In file included from ../dietstdio.h:52, from /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:7: ../include/stdio.h:7:20: stdarg.h: No such file or directory In file included from ../dietstdio.h:52, from /home/blitz/src/l4/pkg/dietlibc/lib/dietlibc/lib/__v_printf.c:7: The include directories look bogus, but I am quite puzzled where they come from. Maybe my directory layout is somehow different from what is expected? Any hint is greatly appreciated. Regards, -- Julian Stecklina Lisp nearing the age of 50 is the most modern language out there. GC, dynamic, reflective, the best OO model extant including GFs, procedural macros, and the only thing old-fashioned about it is that it is compiled and fast. -- Kenny Tilton, comp.lang.python

4 9

[Fwd: Re: Inspect L4Linux Memory]
by Julian Grizzard 15 Sep '05

15 Sep '05

Forgot to copy to list...message below -------- Original Message -------- Subject: Re: Inspect L4Linux Memory Date: Tue, 13 Sep 2005 14:12:14 -0400 From: Julian Grizzard <grizzard(a)ece.gatech.edu> To: Marcus Voelp <voelp(a)os.inf.tu-dresden.de> References: <432214B5.8010109(a)ece.gatech.edu> <43225D54.7040009(a)os.inf.tu-dresden.de> Marcus and all, I like option two better: sharing the dataspace that provides L4Linux with memory. After studying docs under l4/pkg/dm_phys/doc/dm_phys/html, seems like first I need to make an l4dm_share call from the L4Linux server. Then, I should be able make an l4dm_map call from the isolated L4 task. Does this sound like the right general approach? Also, I have a question about the examples under l4/pkg/dm_phys/examples. Take list_ds. There is a call to "if_l4dm_generic_list_call". Where is this call defined? It's not clearly locatable in the API? Is this an IDL thing? I'm not too familiar with IDL. Thanks! -Julian Marcus Voelp wrote: > Hi, > there are actually two nice ways how you can access L4Linux kernel > memory. The first is to install a driver to L4Linux which creates an L4 > thread that in turn would read out the memory when requested to do so. > The second is mapping the L4Linux memory to your external observer by > sharing the dataspace that provides L4Linux with memory. > > The first solution obviously is not suited when reading out much data > and you also rely on the thread to live (i.e., if Linux crashes there is > the chance that the driver thread crashes as well). The second solution > provides a faster read access and survives also kernel crashes. > > Regards > Marcus > > Julian Grizzard wrote: > >> Hi all, >> >> I am running L4Linux 2.6 on Fiasco using L4Env. I would like to build >> an isolated L4 task that can inspect the contents of the L4Linux task >> state. Any pointers on the best way to do this? Conceivably, I could >> map the contents of the L4Linux task into my isolated L4 task to read >> the memory, but I'm not sure the best way to do this. >> >> Thanks! >> >> -Julian >> >> _______________________________________________ >> l4-hackers mailing list >> l4-hackers(a)os.inf.tu-dresden.de >> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers >> >> >

3 2

Inspect L4Linux Memory
by Julian Grizzard 10 Sep '05

10 Sep '05

Hi all, I am running L4Linux 2.6 on Fiasco using L4Env. I would like to build an isolated L4 task that can inspect the contents of the L4Linux task state. Any pointers on the best way to do this? Conceivably, I could map the contents of the L4Linux task into my isolated L4 task to read the memory, but I'm not sure the best way to do this. Thanks! -Julian

2 1

Re: Reboot does not work anymore!
by Derick Swanepoel 08 Sep '05

08 Sep '05

Very sorry, this should've gone to the list. ---------- Forwarded message ---------- From: Derick Swanepoel <dswanepoel(a)gmail.com> Date: 08-Sep-2005 12:21 Subject: Re: Reboot does not work anymore! To: Frank Mehnert <fm3(a)os.inf.tu-dresden.de> On 8/17/05, Frank Mehnert <fm3(a)os.inf.tu-dresden.de> wrote: > On Wednesday 17 August 2005 15:48, Leon Brits wrote: > > > Should not does any matter. But how do you set the video mode, via GRUB > > > vbeset of via --vbemode parameter of l4con? > > > > grub > > Hmm. Very strange. When you reboot via the l4con console you most probably > mean the pkg/loader/example/run program. Could you please disassemble that > binary > > objdump -ld loader/example/run/OBJ-x86_586-l4v2/run | less > > and search for pc_reset, right? That function should come from oskit10 and > we did not change anything there. Hi, I'm having the same problem (CVS 20050829). Rebooting does not work from "run" or from JDB. It gets as far saying: Return reboots, "k" enters L4 kernel debugger... Rebooting. Shutting down... but then nothing happens. This is on a Pentium 4 machine. Strangely, however, it works on a Xeon. For what it's worth, here is the disassembled pc_reset(): 013082f0 <pc_reset>: pc_reset(): ../kern/x86/pc/reset.c:30 13082f0: 55 push %ebp 13082f1: 89 e5 mov %esp,%ebp 13082f3: 53 push %ebx 13082f4: 50 push %eax 13082f5: bb 63 00 00 00 mov $0x63,%ebx ../kern/x86/pc/reset.c:34 13082fa: a1 ec 05 31 01 mov 0x13105ec,%eax 13082ff: 66 c7 80 72 04 00 00 movw $0x1234,0x472(%eax) 1308306: 34 12 ../kern/x86/pc/reset.c:39 1308308: 83 ec 0c sub $0xc,%esp 130830b: 68 fe 00 00 00 push $0xfe 1308310: e8 1b 00 00 00 call 1308330 <kb_command> ../kern/x86/pc/reset.c:37 1308315: 83 c4 10 add $0x10,%esp 1308318: 4b dec %ebx 1308319: 79 ed jns 1308308 <pc_reset+0x18> ../kern/x86/pc/reset.c:45 130831b: 0f 01 1d 9e 04 31 01 lidtl 0x131049e ../kern/x86/pc/reset.c:46 1308322: cc int3 1308323: 8b 5d fc mov 0xfffffffc(%ebp),%ebx 1308326: c9 leave 1308327: c3 ret Thanks, Derick

2 1

Sawmill's dataspaces and the Hurd's physmem
by Neal H. Walfield 06 Sep '05

06 Sep '05

During my presentation of the design of the Hurd on L4 to the Dresden group, Lars Reuther asked me if I had considered Sawmill's dataspace model and if so why I had rejected it. My answer was that we want to be able to catch any errors at the time of data acquisition and that relying on a file system server to provide a mapping to the data does not guarantee this: a malicious server can unmap mappings and refuse to remap them; or if the server is shorter lived than the client, the the data becomes inaccessible to the client when the server exits. Lars asked for more details. Unfortunately, I failed to provide a coherent and complete argument: my problem was mainly that I came to this conclusion fairly early in the design process and had since forgotten too many details of Sawmill's architecture to reconstruct my argumentation. I've recently revisited some related issues and am now in a position to better answer Lars's question. My primary reference for the Sawmill framework is [1]. I think I may be able to best explain the problem with an illustration: consider a server providing access to a file system backed by a disk. In the Sawmill dataspace model [1], the file system server is a dataspace manager which likely provides a dataspace for each file. When a task wants to use a file, it first identifies the dataspace associated with the file (e.g. gets a capability to the file from the DM) and attaches it to its address space (e.g. tells its pager to associate a portion of the VM with the capability). "After an attach, the region mapping forwards all page fault requests in that region to the dataspace manager. The dataspace manager resolves the faults with map or grant operations." I understand this to mean that a client depends on a DM to: - provide mappings to data - provide resources backing the data When a client requests some data from a dataspace, the DM provides a mapping to the client. The client can proceed to use the data, however, at any point, the server could cause the mapping to be unmapped and possibly render the data inaccessible. The implication is that the client must either trust the server to always provide the mapping or be prepared to recover should the data disappear. The latter approach can be simplified by making a physical copy of data before committing to using it (which can be done by interposing a second DM between the DM and the client). General use of this tactic means a lot of cycles will be spent copying bytes and a reduction in the amount of physical memory sharing in the system. DMs appear to use their own resources to fetch and store data as well as to hold data (neither [1] nor [2] mentions any mechanism for the client to specify to the DM what memory/data space to read data into). I assume that the normal mode of operation is that a file system DM has a certain amount of physical memory available from a "physical memory" DM which it uses to hold data from backing store. Once that memory is exhausted, it must choose some page to evict. There are several problems with this model: because DMs allocate resources on behalf of clients resources are allocated with the priority of the DM and resource accounting is extremely difficult. We know this from our experience with the Hurd on Mach. Moreover, the DM controls the paging policy; not the clients who are actively using the memory. To control the availability of memory, it would seem that a client would again have to copy the data. [ Physmem DM ] | v [ FS DM ] | v [ client ] The framework that I have developed for the Hurd avoids these dependencies on the file system servers. The physical memory manager ("physmem") is part of the TCB. physmem provides capabilities to so-called containers which identify memory reservations (either specific, e.g. a specific set of frames, or general, e.g. a specific number of frames). Given a container capability, the holder can map the contents or logically copy the contains to or from a second container. When a task wants to read data from a file, it passes a container capability to the file system server. The file system server stores the data in the container (if it already read it into memory then it can logically copy it). Then it returns to the client. If the task wants a mapping to the data, it requests one from physmem. Thus, tasks on the Hurd do not depend on file system server to provide mappings. After the read is complete, the task knows that the data is either available or not available. If the file system server exits, this does not affect the data that the client has. [ physmem ] / \ |_ _| [ client ] [ FS ] Because the client passes containers to the server, the server does not allocate memory to store the data on behalf of the client. (The server may need other resources such as CPU time, I/O bandwidth and state, however, we have other provisions for that.) Thus memory allocations are directly attributed to the client which is vital to the correct functioning of accounting. Also, when the client has exhausted its memory quota, it must free some memory before it can allocate a container with the required reserve. Thus, clients fully control their own paging policy. One of the goals of the Hurd framework is to minimize the number of dependencies that a client has on the behavior of servers. This is important to us because clients often interact with other users's servers which may be malicious. Another goal is to more directly link consumers of resources with resource allocators. Our observation is that many applications are hurt due to policies such as the eviction scheme imposed by the OS. Moreover, applications such as garbage collectors and multimedia applications could benefit from knowing how much real resource is actually available to them. (Applications should work in harmony with the mechanisms provided to them and the policies imposed on them; they should not have to work around them.) Thanks. I have tried to be as concise as possible which means I may have missed some details. I am particularly interested in the thoughts of the Sawmill and DROPS developpers. Neal [1] http://l4ka.org/publications/2001/sawmill-framework.pdf [2] http://os.inf.tu-dresden.de/l4env/doc/l4env-concept/l4env.pdf

4 6

DROPS build success on FreeBSD
by Julian Stecklina 04 Sep '05

04 Sep '05

Hello, I managed to compile most (the documentation fails with latex errors) of DROPS using the attached patch on FreeBSD 5.4. Notes on how to build drops on L4 are attached as well. Notable difficulties in porting: * bash assumed to be in /bin/ (solved with sed) * assuming Linux-style /proc in gendep * assuming dynamically-linked gcc It might be worthwile to make kernel/fiasco/src/Makeconf include mk/Makeconf to avoid redundancy. I think the whole build process would be quite portable with some autoconf magic and with gendep removed. Also I did not test the result. Maybe tomorrow. Regards, -- Julian Stecklina (Of course SML does have its weaknesses, but by comparison, a discussion of C++'s strengths and flaws always sounds like an argument about whether one should face north or east when one is sacrificing one's goat to the rain god.) -- Thant Tessman

1 1

gendep on FreeBSD
by Julian Stecklina 03 Sep '05

03 Sep '05

Hello, in my quest to get the Fiasco tree buildable on FreeBSD I encountered the following problem (this is with gendep compiled with VERBOSE=1) [...] echo BID_LIBGENDEP=/home/blitz/src/l4/tool/gendep/libgendep.so >>./.Makeconf.bid.converted; echo 'BUILD_PIC += $(BUILD_LOADER_PICS)' >>>>./.Makeconf.bid.converted set -e; X="tmp.$$$RANDOM.c" ; echo 'int main(void){}'>$X ; rm -f $X.out ; LD_PRELOAD=/home/blitz/src/l4/tool/gendep/libgendep.so GENDEP_SOURCE=$X GENDEP_OUTPUT=$X.out gcc33 -c $X -o $X.o; test -e $X.out; echo INT_CPP_x86_NAME=`cat $X.out` >>./.Makeconf.bid.converted; rm -f $X $X.{o,out}; fopen(/proc/self/cmdline) real_fopen(/proc/self/cmdline) gendep: Cannot resolve fopen(): Unknown error: 0 It seems that RTLD magic is somehow broken, but I cannot say how... if someone has a hint, I am all ears. My patches to gendep are attached. Regards, -- Julian Stecklina (Of course SML does have its weaknesses, but by comparison, a discussion of C++'s strengths and flaws always sounds like an argument about whether one should face north or east when one is sacrificing one's goat to the rain god.) -- Thant Tessman

1 1

Fiasco CVS repository
by Julian Stecklina 03 Sep '05

03 Sep '05

Hello, I have some problems with the CVS repository for Fiasco: cvs diff: failed to create lock directory for `/home/remote-cvs/l4/tool/twiddler' (/home/remote-cvs/l4/tool/twiddler/#cvs.lock): A file or directory in the path name does not exist. cvs diff: failed to obtain dir lock in repository `/home/remote-cvs/l4/tool/twiddler' cvs [diff aborted]: read lock failed - giving up Same goes with 'update' always in the twiddler directory. Regards, -- Julian Stecklina (Of course SML does have its weaknesses, but by comparison, a discussion of C++'s strengths and flaws always sounds like an argument about whether one should face north or east when one is sacrificing one's goat to the rain god.) -- Thant Tessman

2 2

RE: Critics on L4 (NOT Re: shared memory Beispiel?)
by yuan Darwin-r62832 02 Sep '05

02 Sep '05

Hi, >Hi L4Ka::Pistachio developers, > >I have read the source code of L4Ka::Pistachio-0.4. & found that some >features defined in L4 eXperimental Kernel Reference Manual Version X.2 Revision 5 hasn't been implemented yet. For example, appoint redirector by SpaceControl, IO port mapping, etc. > > Please understand that both Pistachio and Fiasco are research prototypes and that the L4 eXperimental Kernel Reference Manual is indeed EXPERIMENTAL which means that it may change unnoticed and which also means that the prototypes may differ from the specification. The missing features that you state are published, e.g., at http://l4ka.org/projects/pistachio/ia32/ under the section Missing Features / Known Bugs for the Pistachio kernel , respectively at http://os.inf.tu-dresden.de/fiasco/status.html for Fiasco. [Darwin Yuan] Thanks for your information, I started to learn L4 just 1 month. A totally junior. Anything I was wrong, pls correct me. >I tried to checkout the newest source code from CVS, & the CVS server >cvs.l4ka.org couldn't be reached. > > I had no problems reaching the server. Though I cannot confirm that it was up all the time. [Darwin Yuan] Thanks, I'll try later. >When those features are going to be implemented? > Fiasco implements IO Flexpages. Neither Redirectors nor Clans and Chiefs are currently implemented in Fiasco and probably never will. I cannot speak for plans regarding Pistachio. [Darwin Yuan] I didn't read the source code of Fiasco. However, from the documents I got from its website, I found that Clans & Chiefs was implemented in its kernel ( It might be removed now). But I don't think it's a good design that this policy was involved in L4 kernel, now that L4 claims it's a real microkernel. However, I think those kind of policies could be implemented outside kernel. Therefore, I think Redirector is a good mechanism to achieve those kind of policies. That's why I think redirector is very important for implementing a flexible system on L4. >Now that those features are very important for implementing a flexible >OS on L4 u-kernel. > > Both redirectors and IO flexpages are not essential to get a system up and running. Their purpose is to control and restrict communication between threads respectively to prevent a thread from reading / writing IO-ports. Feel free to implement those features if you need them. [Darwin Yuan] Yes, That's true. However, a real system should makes peripheral equipment work. IO Fpage is very essential for implementing hardware driver. Can you elaborate on why you thing missing these features prevents someone building a flexible OS on L4? [Darwin Yuan] As mentioned above. >Seems that there are so many differences between L4Ka::Pistachio and >Fiasco. Is there a stardard L4 specification? > There is a standard L4 Specification: L4-V2 by Jochen Liedtke. Also there is the eXperimental specification you already found which is the defacto standard for L4-V4 kernels. The main difference between Pistachio and Fiasco is that the former implements L4-V4, the latter implements L4-V2 whereby some experimental features have been incorporated into Fiasco to better suite our user level software's needs. As you will see Fiasco already implements some parts of the L4-V4 specification. [Darwin Yuan] I see. Thanks. >I think L4Ka::Pistachio is more clean & flexible, why Fiasco put so >many complicated & inflexible policies inside L4 kernel? > > Which policies are you referring to? Can you elaborate on these points? [Darwin Yuan] For example, Clans & Chiefs. Also, I think "Task" is a redundant abstract/concept, "Address Space" is a much better one. By "Thread" & "Address Space", L4Ka::Pistachio makes the abstract very refined, and allows to construct very flexible system. All together, the APIs of X.2 is much better than X.0. >BTW, has any OS or system been built on L4Ka::Pistachio? As I know, >L4-Linux is built on Fiasco, but I don't like its design. I hope I can >get a reference system based on L4Ka::Pistachio. > > > Lets see, there is L4 Linux which runs on both Fiasco and Pistachio, L4 Env, Drops runs on Fiasco, Kenge, Iguana and Wombat on Pistachio. Also there is Mungi, Perseus, L4 Hurd, etc. Have a look at l4hq.org and you may find out much more. [Darwin Yuan] Thanks for your information. Why don't you like the design of L4Linux or do you mean Fiasco? [Darwin Yuan] Actually, I don't like the APIs & mechanism of Fiasco. Now that L4Linux is based on those APIs & mechanism, I don't like this version of L4Linux. Some more final words: It is common practice on mailing lists to start a new topic if you are referring to a totally different topic. [Darwin Yuan] Honestly, I never use any public mailling list before:(. 'cause this original mail is the first mail I got from this mailing list, I replied it. Someone else has told me about that. Thanks anyway. Best regards Marcus -- Marcus Völp TU-Dresden Department of Computer Science Institute for System Architecture Tel: +49 (351) 463-38350 Fax: +49 (351) 463-38284

5 5