- l4-hackers - example.com Site

Re: What is RMGR?
by Michael Hohmuth 10 May '99

10 May '99

°í¿µ¿õ <yuko(a)os.korea.ac.kr> writes: > Anyone know the relation between L4 and RMGR? > I cannot understand. -_- > > I want to know > 1) If L4 kernel could boot without RMGR?. RMGR is essential part of L4? Yes, and no, respectively. It is well possible to construct L4-based or Fiasco-based systems without Rmgr, and we have done so in the past. However, nowadays we always use Rmgr because it provides a very convenient way for bootstrapping a system. > 2) If it is essential module for L4, the size of L4 microkernel must > include RMGR size? Even then it probably wouldn't count because once the system is up and running, Rmgr is mostly idle. It certainly doesn't hurt the system performance because it doesn't induce a measurable load on the CPU caches. > I want to get related papers or documentation. Except for the manpage at <URL:http://os.inf.tu-dresden.de/L4/l4libman/rmgr.html>, there aren't any. Rmgr just happens to be an application everyone uses. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

GMD paper
by Adam 'WeirdArms' Wiggins 10 May '99

10 May '99

Anyone know where I can get a copy of: Jochen Liedtke: Improved Address Space Switching on Pentium Processors by Transparently Multiplexing User Address Spaces (GMD technical report) Cheers Adam

2 1

Re: New Fiasco snapshot
by Michael Hohmuth 10 May '99

10 May '99

David Welch <david.welch(a)st-edmund-hall.oxford.ac.uk> writes: > I am having problems using the snapshot. It builds and boots > ok but as soon as I try to fork/exec another program it freezes. > > I am using a Cyrix processor (without the 4MB page extensions), > and the latest Fiasco snapshot (including the released patches) as > well as the latest L4Linux server and patches. [...] I suppose by fork/exec you mean the corresponding L4Linux system calls? If your problem is related to your CPU not having 4MB-page extensions, then there's a good chance that I will come across it this week: Other people have reported problems with non-Pentium CPUs too, so my sysadmin has organized an old 486 for me to debug Fiasco on. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: L4 threadid ver0 and ver1 bits
by Michael Hohmuth 10 May '99

10 May '99

"Adam 'WeirdArms' Wiggins" <awiggins(a)cse.unsw.edu.au> writes: > I think they were seperate in the Intel for efficiency reasons, Yes, that's right: The way the bits are laid out in thread ids, it takes the kernel only one AND and one OR to compute the address of the thread control block; no shifts or lookups necessary. (Fiasco actually currently adds a shift because the kernel stack contained in the thread control blocks is larger to accommodate for the fact that higher-level languages need more stack space.) Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

L4 threadid ver0 and ver1 bits
by Daniel Potts 10 May '99

10 May '99

Hi, What is the precise meaning of the ver0 and ver1 bits in the L4 thread ids? Cheers, Daniel

2 3

New Fiasco snapshot
by Michael Hohmuth 10 May '99

10 May '99

Hackers, I've made available a new Fiasco source code snapshot (990428), nicknamed version 0.6. It contains numerous bug fixes and two new features: - Long-message IPC has been implemented (but hasn't yet been tested extensively). - Jean Wolter has contributed a new stand-alone kernel debugger. It allows you to see critical kernel state on your text console. I've also released new snapshots for the L4 runtime support (required) and for our version of the OSKit, as well as a new patch for L4Linux. Please find the stuff here: ftp://ftp.inf.tu-dresden.de/pub/os/L4/fiasco/fiasco-l4-990428.tar.gz ftp://ftp.inf.tu-dresden.de/pub/os/L4/devel/l4-990428.tar.gz ftp://ftp.inf.tu-dresden.de/pub/os/L4/devel/oskit-l4-990428.tar.gz ftp://ftp.inf.tu-dresden.de/pub/os/L4/devel/linux-l4-981207.patch-02.gz Our admins are busy figuring out how to allow CVS access from the outside world. In the future this will allow you to access up-to-date source code without waiting for a new snapshot. Please visit <URL:http://os.inf.tu-dresden.de/fiasco/use.html> for updated build instructions. Have fun! Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: Patch for Fiasco 0.6
by Michael Hohmuth 04 May '99

04 May '99

kermit the frog <kermit(a)tower.com.ar> writes: > Well, what i saw is that the WHOLE directory structure changed ... and the > Makefile has a -I/home/drops (or something) which doesnt seems to be > needed since Fiasco compiles anyway ... These changes allow people working on only part of the source tree to check out (or unpack) only what they're working on and otherwise use what's been installed in /home/drops (DROPS_STDDIR in l4/Makeconf). > It would be nice to have the old dir. structure back ... (; It will get even better (read: more confusing ;) in the next snapshot: We've moved all include files to package-specific subdirectories to reduce clutter in <l4/*.h>, requiring changes to many source files (e.g., <l4/ipc.h> becomes <l4/sys/ipc.h>). We thought that indroducing some software-development guidelines now would hurt less than introducing them later. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Patch for Fiasco 0.6
by Michael Hohmuth 04 May '99

04 May '99

It looks like the Fiasco-0.6 snapshot has been sewed together with too hot a needle (thanks to Hoi-sun lee for reporting this problem). Please apply the patch appended below to make it compile. (This patch will also appear on the Fiasco ftp site as fiasco-l4-990428.patch-01.gz.) Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

deceit operations for clans+chiefs.
by Daniel Potts 01 May '99

01 May '99

Assume task A is the chief of task B, which is the chief of task C, which is the chief of task D. ;-) * Now, D does an ipc call to A. A successfully receives the message from D via the chiefs (C and B). * Now when A replies to this, the message first gets intercepted by B. * B sends a deceiting ipc to D with A as the virtual sender. This gets intercepted by C. * C sends a deceiting ipc to D with A as the virtual sender. This step fails (?!) due to direction preservation not holding. That is when C checks nchief on A it returns L4_NC_OUTER_CLAN, and nchief on D returns L4_NC_SAME_CLAN, which is not equal, and therefore not direction preserving. Have I got this scenario correct? Assuming that each cheif can obtain the virtual sender as part of it's ipc api. Cheers, Daniel

2 2

Re: Still missing something ...
by Michael Hohmuth 28 Apr '99

28 Apr '99

kermit the frog <kermit(a)tower.com.ar> writes: > Hello, thanks for always answering (im such a pain in the ... (-: > > Well, this time, after following Michael's instructions (heres a piece of > the code) : > th = l4_myself(); > printf("rmgr_init()\n"); > rmgr_init(); > printf("Hello, task: %d, thread: %d\n", th.id.task, th.id.lthread); > > sigma0.id.task = 2; > sigma0.id.lthread = 0; > > recv.id.task = rmgr_get_task(6); > recv.id.chief = th.id.task ; > recv.id.lthread = 0; > recv = l4_task_new(recv, 5, (dword_t) task+(4096*2), (dword_t)task, > sigma0); > > All i get is : 'sys_id_nearest' > > What is that ?? Argh, the library code snippet I sent you uses l4_nchief(), a binding for the sys_id_nearest system call, a call which has only been fixed recently. I really should release a new code snapshot... I'll try to do this later today (and I'll try to make the source code more accessible in order to avoid such problems in the future). For now, you can try the Fiasco patch below, or you can modify the librmgr.c file I sent you to find out its Rmgr server by querying its pager using l4_thread_ex_regs() instead of using l4_nchief() -- just change the "#if 0" in rmgr_init() to "#if 1". Sorry, Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0