- l4-hackers - example.com Site

[Patch] Bochs with 4M superpages runs L4Ka
by Farid Hajji 19 Oct '00

19 Oct '00

Hi, [Kevin: would you please have a closer look at this patch? I'm not an x86 expert and this is at best a premature first try at it. -Thanks] the following patch: http://home.kamp.net/home/farid.hajji/l4ka-bochs/ enables 4 MB superpages in bochs. With this hack, you can boot (among others) L4Ka+root_task without problems on your favorite workstation ;-) (at least I hope so!). Please refer to the file SUPERPAGES in the patched bochs sources for a quick overview. General instructions and screen shots can be found on the above URL. BEWARE: That hack is very alpha and not tested at all! Don't rely on it too much for now. At least, it won't destroy your system, since everything is emulated in software. Bochs may be slow (it is!) but at least it's more secure than plex86 or vmware and it runs on non- intel boxes too. If you find any bugs (e.g. bochs panics()), please try to track them down and fix the sources as far as possible. It is easier than it sounds because bochs sources are very clear and because you can insert printf()s everywhere. Try this with a real processor! Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

1 0

Re: Task generation & Fiasco scheduler
by Michael Hohmuth 17 Oct '00

17 Oct '00

"kargahi"<kargahi(a)moe.or.ir> writes: > 1. I tried more than a few times to create a 'task' with the l4_task_new > system call but i couldn't. If possible, please send me some examples and > describtion on creating tasks except the L4 manuals. In order to create a new task using l4_task_new, you need to own a task-creation right first. You can get one from Rmgr using the librmgr.a library call rmgr_get_task(). After that, l4_task_new() should work. Also, please don't forget that the new task needs a pager. I'll append a simple example below. > 2. I am looking for the manager of resource CPU( scheduler ). Please guide > me that where is the scheduler and how i can change it with my algorithm. Most of it is implemented in thread_t::schedule(). Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: Real-time Fiasco
by Michael Hohmuth 17 Oct '00

17 Oct '00

"kargahi"<kargahi(a)moe.or.ir> writes: > Would you please say me why Fiasco is a real-time u-kernel & what > are the real-time properties of Fiasco? For Fiasco, "Real-Time" means that Fiasco implements static ``hard'' thread priorities, and the worst-case time to react to an event such as an interrupt or a timeout are bound. To keep the bound low, Fiasco is is fully preemtible in kernel mode, and it guarantees that ``independent thread groups'' are always executable no matter what is going on in the kernel. > After that, please say me how the priorities affect the timeslice of a task > and where the timeslice of a task is allocated to it. The scheduler uses two variables: Priorities determine the order in which threads are executed (thread_t::schedule()). The time-slice length determines when the kernel considers running a different thread of the same priority. The kernel has the concept of a "current time slice" which is the number of clock ticks the current thread can execute without being preempted. The current time slice (timeslice_ticks_left) is checked in thread_timer_interrupt(), and it is initialized in thread_t::schedule(). Please not that it is not set on every kernel-context switch -- only when a thread is preempted or voluntarily goes to sleep (that is, only in thread_t::schedule(), not in thread_t::switch_to()). Different L4 kernels handle scheduling differently. Jean Wolter has a short paper describing the current state of the art for some L4 implementations that I'm sure he will make available for the asking. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: L4ka and Bochs (was: L4ka and plex86?)
by Farid Hajji 16 Oct '00

16 Oct '00

Hi Volkmar and Kevin, trying to get l4ka running under bochs would probably require slight modifications to the bochs sources, so that 4 MB pages (bit 4 PSE of CR4) can be supported (please see summary below). > ------------------ BoSnip ------------------- > > // Only allow writes of 0 to CR4 for now. > > // Writes to bits in CR4 should not be 1s as CPUID > > // returns not-supported for all of these features. > ------------------ EoSnip ------------------- > > So what happens is that we initialize 4MB pages (located in the first level > page dirs). > If bochs does not support 4MB pages - you are pretty much out of luck - we > currently do not support > 4K pages only. The kernels virtual view of physical memory is mapped as 4MB > pages. Furthermore, > RMGR and L4Linux assumes 4MB/Super-pages. So if you have absolutely no > possibility to get a normal > Pentium System - we have to do some mid-major :) changes of the startup > code. I don't hope that it would be necessary to tweak the l4ka sources so much (at least not for that 4MB problem). Looking at the sources of bochs, I think that it would be _much_ easier to add support for the PSE bit (bit 4 of CR4) to bochs itself at two places, rather than modifying l4ka. This is what I've found out so far (sorry for lengthy message): ---------- cut here ----------- cut here ------------- cut here -------------- Summary: ======== 1. About superpages, PSE bit etc... - - - - - - - - - - - - - - - - - - Intel Architecture Software Developer's Manual Volume 3: System Programming Order-Nr: 243192 http://developer.intel.com/design/pentiumii/manuals/24319202.pdf Section 3.6 Paging (Virtual Memory): PG-Flag (Bit 31 of CR0) enables paging translation, >= 386 PSE-Flag (Bit 4 of CR4) 4k or 4MB pages, >= 586 PAE-Flag (Bit 5 of CR4) 36Bit physical addr, >= 686 Section 3.6.2.1 Linear Address Translation (4 kByte Pages) Section 3.6.2.2 Linear Address Translation (4 MByte Pages) Section 3.6.2.3 Mixing 4kByte and 4MByte pages Section 3.8.2 Linear Address Translation With Extended Adressing Enabled (2 MByte or 4 MByte Pages). ====> PSE bit is only used while translating linear addresses to physical ====> addresses. paging directory entries and page table entries have slighly ====> different format (?) when 4 MB pages are involved. See figures ====> 3-14, 3-15, 3-18, 3-19, 3-20, 3-21. ====> In bochs, this is mainly located in the file: ====> bochs-2000_0325a/cpu/paging.cc 2. L4ka sources - - - - - - - - 2.1: l4-ka/kernel/src/x86/init.c:init_paging() .............................................. #if defined(CONFIG_ARCH_X86_I586) || defined(CONFIG_ARCH_X86_I686) /* Turn on super pages. */ enable_super_pages(); #endif ====> I configured with CONFIG_ARCH_X86_I586 to avoid having to: ====> #if defined(CONFIG_ARCH_X86_I686) ====> enable_global_pages(); ====> setup_sysenter_msrs(); ====> #endif 2.2: l4-ka/kernel/include/x86/cpu.h:enable_super_pages() ........................................................ INLINE void enable_super_pages() { __asm__ __volatile__ ("mov %%cr4, %%eax\n" "orl $0x10, %%eax\n" "mov %%eax, %%cr4\n" : : : "eax"); } ====> Turning on bit 4 of CR4 (PSE) enables 4 MB pages. ====> Volkmar: In Section 3.6.2.2 (at the End), the note says ====> Volkmar: that the TLBs _must_ be flushed (invalidated) after setting ====> Volkmar: or clearing the PSE bit. Forgot to do it? ====> This is the instruction that crashes bochs. 3. Bochs sources: - - - - - - - - - 3.1 output of bochs.out logfile: ................................ WBINVD: (ignoring) MOV_RdCd: read of CR4 MOV_CdRd: ignoring write to CR4 of 0x00000010 bochs: panic, MOV_CdRd: (CR4) write of 0x00000010 >> mov CR4, EAX ====> Bochs panic()s because it doesn't support CR4 bits yet (see below). ====> l4ka (enable_super_pages()) tries to set the PSE bit in CR4 because ====> it needs 4 MB superpages. 3.2 bochs-2000_0325a/cpu/proc_ctrl.cc: ...................................... This file contains the implementation of the x86-instructions. Let's look at the missing/buggy parts that were reported in bochs.out above: 3.2.1: WBINVD: (ignoring): . . . . . . . . . . . . . void BX_CPU_C::WBINVD(BxInstruction_t *i) { bx_printf("WBINVD: (ignoring)\n"); #if BX_CPU_LEVEL >= 4 invalidate_prefetch_q(); if (BX_CPU_THIS_PTR cr0.pe) { if (CPL!=0) { bx_printf("WBINVD: CPL!=0\n"); exception(BX_GP_EXCEPTION, 0, 0); } } BX_INSTR_CACHE_CNTRL(BX_INSTR_WBINVD); #else UndefinedOpcode(i); #endif } ====> BX_CPU_LEVEL was defined to be 5, so invalidate_prefetch_q() ====> was called. WBINVD (invalidates TLB etc...) seems to be okay. 3.2.2: read of CR4: . . . . . . . . . . void BX_CPU_C::MOV_RdCd(BxInstruction_t *i) { // mov control register data to register <snip> case 4: // CR4 #if BX_CPU_LEVEL == 3 val_32 = 0; bx_printf("MOV_RdCd: read of CR4 causes #UD\n"); UndefinedOpcode(i); #else bx_printf("MOV_RdCd: read of CR4\n"); val_32 = BX_CPU_THIS_PTR cr4; #endif break; <snip> } ====> This seems to be okay once more. The contents of the variable ====> cr4 can be read on this BX_CPU_LEVEL of 5. 3.2.3: ignoring write to CR4 of 0x00000010....., then panic() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . void BX_CPU_C::MOV_CdRd(BxInstruction_t *i) { // mov general register data to control register <snip> case 4: // CR4 #if BX_CPU_LEVEL == 3 bx_panic("MOV_CdRd: write to CR4 of 0x%08x on 386\n", val_32); UndefinedOpcode(i); #else // Protected mode: #GP(0) if attempt to write a 1 to // any reserved bit of CR4 bx_printf("MOV_CdRd: ignoring write to CR4 of 0x%08x\n", val_32); if (val_32) { bx_panic("MOV_CdRd: (CR4) write of 0x%08x\n", val_32); } // Only allow writes of 0 to CR4 for now. // Writes to bits in CR4 should not be 1s as CPUID // returns not-supported for all of these features. BX_CPU_THIS_PTR cr4 = 0; #endif break; <snip> } ====> This has to be tweaked, perhaps by adding a call to a new ====> CR4_change() function (like CR3_change()), which can ====> then be added to paging.cc. If the change is minimal, ====> modifying variable cr4 directly may be enough. Anyway, ====> in paging.cc, the translation functions must take into ====> account the PSE bit it cr4!!! 3.3 bochs-2000_0325a/cpu/paging.cc .................................. // Translate a linear address to a physical address, for // a data access (D) Bit32u BX_CPU_C::dtranslate_linear(Bit32u laddress, unsigned pl, unsigned rw) { <snip long code which uses cr0, cr3 but not cr4 (yet)> } // Translate a linear address to a physical address, for // an instruction fetch access (I) Bit32u BX_CPU_C::itranslate_linear(Bit32u laddress, unsigned pl) { <snip long code which uses cr0, cr3 but not cr4 (yet)> } ====> these functions will have to additionally take into ====> account the value in cr4 (e.g. PSE bit), so that ====> 4 MB pages are supported. ---------- cut here ----------- cut here ------------- cut here -------------- Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

3 2

Trying L4ka under Bochs/FreeBSD (the saga continues...).
by Farid Hajji 14 Oct '00

14 Oct '00

Hi, [Kevin: please have a look at the bochs panic below: What's wrong with writing non-zero to CR4 when --enable-cpu-level=5 is mentioned? Is there a quick workaround to this problem? Thanks.] I'm trying to run l4ka under bochs but I'm still fighting with some bochs panic()s. This is what I've found out so far: 1. 3 modules _must_ be attached to rmgr, so that the assertion in startup() about the number of modules doesn't bite. 2. I used the following grub startup commands thru all following tests (bochs simulates disk C: from a 112M bytes regular file): grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> kernel (hd0,0)/l4ka/rmgr.debug -sigma0 [Multiboot-elf, <0x111000:0x20734:0x0>, <0x132740:0x48c:0xfcc8>, entry=0x111000] grub> module (hd0,0)/l4ka/x86-kernel [Multiboot-module @ 0x143000, 0x12769 bytes] grub> module (hd0,0)/l4ka/sigma0 [Multiboot-module @ 0x156000, 0x287a bytes] grub> module (hd0,0)/l4ka/glinux [Multiboot-module @ 0x159000, 0x143dd4 bytes] grub> boot rmgr.debug is just original rmgr binary, with another name. I tried to slightly modify rmgr in later steps... rmgr[.debug], x86-kernel and sigma0 were compiled on FreeBSD without problems. Note: compiled for 586, not 686!. They are not stripped. I was not able to compile linux22 from Dresden on FreeBSD, so I just used the binary 'glinux' from your distribution. 3. Without any modifications to the l4-ka sources, bochs panic()s right after displaying the message: check_l4_version 0x00100000 to 0x0011041c with the following error message: MOV_RdCd: read of CR4 MOV_CdRd: ignoring write to CR4 of 0x00000010 bochs: panic, MOV_CdRd: (CR4) write of 0x00000010 protected mode CS.d_b = 32 bit SS.d_b = 32 bit | EAX=00000010 EBX=ff000000 ECX=0010f40f EDX=0010a000 | ESP=0010f3f7 EBP=00109000 ESI=f0109000 EDI=00109000 | IOPL=0 NV UP DI PL NZ NA PO NC | SEG selector base limit G D | SEG sltr(index|ti|rpl) base limit G D | DS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | ES:0010( 0002| 0| 0) 00000000 000fffff 1 1 | FS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | GS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | SS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | CS:0008( 0001| 0| 0) 00000000 000fffff 1 1 | EIP=0010fa55 (0010fa52) >> 77875018 0f77875018 2277875018 e077875018 : mov CR4, EAX bochs was not able to grok the instruction: mov CR4, EAX (that is EAX -> CR4). I compiled bochs-2000_0325a with the following options: ./configure --enable-cpu-level=5 \ --enable-disasm --enable-vga --enable-fpu \ --enable-x86-debugger Support for x86-debugger (DR? registers etc...) is therefore enabled. Looking at the source code of bochs-2000_0325a, file cpu/proc_ctrl.cc says in function void BX_CPU_C::MOV_CdRd(BxInstruction_t *i): [...] case 4: // CR4 #if BX_CPU_LEVEL == 3 bx_panic("MOV_CdRd: write to CR4 of 0x%08x on 386\n", val_32); UndefinedOpcode(i); #else // Protected mode: #GP(0) if attempt to write a 1 to // any reserved bit of CR4 bx_printf("MOV_CdRd: ignoring write to CR4 of 0x%08x\n", val_32); if (val_32) { bx_panic("MOV_CdRd: (CR4) write of 0x%08x\n", val_32); } // Only allow writes of 0 to CR4 for now. // Writes to bits in CR4 should not be 1s as CPUID // returns not-supported for all of these features. BX_CPU_THIS_PTR cr4 = 0; #endif break; [...] So bochs doesn't allow writing 0x00000010 (non-zero) to CR4 for now. To Kevin: Why? To Uwe: Can we avoid having to write to CR4 for now? 4. I tried to localize the exact position of that instruction in l4-ka by adding the following MYDEBUG macro to halt execution before bochs panic()s: #ifndef MYDEBUG #define MYDEBUG(str) { printf(str); for(;;) ; } #endif this helped to track down at least portions of the code that were definitely executed by bochs, as well as to see the output. This is what I've found out so far: 4.1. control definitely reaches the end of l4-ka/apps/rmgr/src/startup.c:startup(), at least just before the final: asm volatile ("pushl $" SYMBOL_NAME_STR(exit)"\n" "pushl %2\n" "ret\n" : /* no output */ : "a" (MULTIBOOT_VALID), "b" (&l4_mbi), "r" (exec_info.entry)); /*NORETURN*/ This is the output in bochs: RMGR: loading (hd0,0)/l4ka/sigma0 check_l4_version 0x00100000 to 0x0011041c RMGR: detected L4-Karlsruhe find kernel info page... found kernel info page at 0x00107000 configuring s0: (0x00200000, 0x00213000), start: 0x00200000 s0 config: 0x00200000,0x00000000,0x00200000,0x00213000 RMGR: reserve modules memory range: 156000 to 29cdd4 RMGR: starting (hd0,0)/l4ka/x86-kernel @ 0x0010f000 >>>> rmgr.debug:startup() just before asm volatile... at end of function. 4.2. control doesn't reach even the very beginning of l4-ka/apps/rmgr/src/init.c:init() where I've put the next MYDEBUG call. bochs panic()s with the same error message as before (ignoring write to CR4 of 0x00000010: mov CR4, EAX). Uwe, where does startup() exactly jumps to? I thought it was rmgr's init()??? Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

1 0

Real-time Fiasco
by kargahi 11 Oct '00

11 Oct '00

Hi L4 Hackers Would you please say me why Fiasco is a real-time u-kernel & what are the real-time properties of Fiasco? After that, please say me how the priorities affect the timeslice of a task and where the timeslice of a task is allocated to it. Thanks.

1 0

Task generation & Fiasco scheduler
by kargahi 18 Sep '00

18 Sep '00

Hi L4 hackers I am trying to write some servers on the L4 MK but i have two problems, please guide me with enough details and simple examples. my problems are here : 1. I tried more than a few times to create a 'task' with the l4_task_new system call but i couldn't. If possible, please send me some examples and describtion on creating tasks except the L4 manuals. 2. I am looking for the manager of resource CPU( scheduler ). Please guide me that where is the scheduler and how i can change it with my algorithm. thanks so much M. KARGAHI

1 0

Compiling L4 on FreeBSD (Part 2)
by Farid Hajji 15 Sep '00

15 Sep '00

Hi Michael, I tried again to compile l4 and I'm a step further: cd l4 mkdir include/l4/log cd include/l4/log ln -s ../../../pkg/log/include/l4/log/l4log.h . Now, gmake bombs with gmake[4]: Entering directory `/tmp/l4-devel/l4/pkg/l4util/examples/perf' gmake[4]: *** No rule to make target `main.ld', needed by `perf_p6'. Stop. How can a main.ld be generated? The two other main.ld I've found: ./pkg/log/server/src/main.ld ./pkg/names/server/src/main.ld were quite old (nov 1999) and certainly not generated by gmake! I'm still suspecting an incomplete l4 distribution, probably due to CVS. Trying to compile oskit10, I'm also missing files (I already told you this). I generated a oskit10/modules.x86.pc manually by putting the name of each subdirectory of oskit10 by itself on a line. Using gcc-2.95.2, configure resumes but misses the following files: sed: ./unsupported/scripts/sym-trace.in: No such file or directory sed: ./boot/GNUmakefile.in: No such file or directory sed: ./examples/GNUmakefile.in: No such file or directory sed: ./freebsd/GNUmakefile.in: No such file or directory sed: ./fs/GNUmakefile.in: No such file or directory sed: ./fsnamespace/GNUmakefile.in: No such file or directory sed: ./linux/GNUmakefile.in: No such file or directory sed: ./netbsd/GNUmakefile.in: No such file or directory sed: ./posix/GNUmakefile.in: No such file or directory sed: ./video/GNUmakefile.in: No such file or directory sed: ./wimp/GNUmakefile.in: No such file or directory sed: ./x11/GNUmakefile.in: No such file or directory Here again, I'm suspecting an incomplete distribution due to cvs problems. Thank you, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

2 3

CVS Server broken? + compiling L4 on FreeBSD
by Farid Hajji 13 Sep '00

13 Sep '00

Hi Michael, I already asked this on l4-hackers, but I didn't get any replies (yet): -------- begin forwarded message ----------- begin forwarded message -------- 1. I'm missing some files, like e.g. in l4 module the file pkg/log/lib/include/l4/liblog.h (among others). [oskit10 is missing _a lot_ of files too, not only .html's] 2. In l4-hackers archive http://www.mail-archive.com/l4-hackers@os.inf.tu-dresden.de/msg00399.html Michael refers to an additional "log" package. This is fine, but this package (included in l4) doesn't include liblog.h (cvs server says: nothing known about pkg/log/lib/include/l4/liblog.h) --------- end forwarded message ------------ end forwarded message -------- I did a complete "checkout l4" again in a fresh directory today, but the problem remained (the same with cvs update -d). One guess may be that the files are not present in the repository or that they have wrong permissions. Could you please check that the cvs server is running correctly (at least for l4 and oskit10)? I'm trying to compile l4 on a FreeBSD machine. I was able to compile oskit (_not_ oskit10) with gcc-2.7.2.3 and binutils-2.9.1 without problems (gcc-2.95.2 couldn't grok some asm directives because of forbidden use of certain x86 regs) except for the usual warnings. Compiling l4 with gcc-2.95.2 and binutils-2.9.1 went well, up to the point where liblog.h is required. I was not able to proceed any further at this point (liblog.h was not present either in l4-990428.tar.gz). BTW, I had to modify l4/Makeconf slightly, so that the native gcc(-2.95.2) of FreeBSD be used instead of the cross-compiler i486-linux-gcc. This is the modified part of l4/Makeconf: ifdef CROSS CPPFLAGS+= -DCROSS ifeq ($(SYSTEM),Linux) SYSTEM_TARGET= FLOPPY=/dev/fd0 else ifeq ($(SYSTEM),FreeBSD) SYSTEM_TARGET= FLOPPY=/dev/rfd0.1440 else SYSTEM_TARGET=i386-linux- endif endif endif I also tried to compile oskit10, but to no avail. Probably due to the missing files problem reported earlier (I'm not sure though...), even oskit10/configure bombed at a very early stage with the following error message: checking if compiler groks __attribute__((packed)) on structs... yes checking if compiler groks __attribute__((pure))... yes checking if compiler groks __attribute__((noreturn))... yes checking if compiler groks __attribute__((constructor))... yes configure: error: OSKit modules file ./modules.x86.pc was not found. It didn't matter wether I used gcc-2.95.2 or gcc-2.7.2.3: env CC=gcc27 MAKE=gmake ./configure env CC=gcc MAKE=gmake ./configure This is my compile environment: gcc -v Using builtin specs. gcc version 2.95.2 19991024 (release) gcc27 -v Reading specs from /usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/2.7.2.3/specs gcc version 2.7.2.3 as -v GNU assembler version 2.9.1 (i386-unknown-freebsdelf), using BFD version 2.9.1 ld -v GNU ld version 2.9.1 (with BFD 2.9.1) gmake -v GNU Make version 3.79, by Richard Stallman and Roland McGrath. Built for i386--freebsd5.0 uname -rs FreeBSD 5.0-20000506-CURRENT Please help! Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

1 0

CVS server problems?
by Farid Hajji 12 Sep '00

12 Sep '00

Hi, is the CVS server currently broken? 1. I'm missing some files, like e.g. in l4 module the file pkg/log/lib/include/l4/liblog.h (among others). [oskit10 is missing _a lot_ of files too] 2. In l4-hackers archive http://www.mail-archive.com/l4-hackers@os.inf.tu-dresden.de/msg00399.html Michael refers to an additional "log" package. This is fine, but this package (included in l4) doesn't include liblog.h (cvs server says: nothing known about pkg/log/lib/include/l4/liblog.h) Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

1 0