l4-hackers

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

2827 discussions

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

Still missing something ...
by kermit the frog 28 Apr '99

28 Apr '99

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 ?? Cheers. Cervi~no Ulises <kermit(a)tower.com.ar> <c-3087-2(a)unrctu.edu.ar> ...............................................................................

1 0

Re: Am i missing something here ?
by Michael Hohmuth 27 Apr '99

27 Apr '99

kermit the frog <kermit(a)tower.com.ar> writes: > First of all, thanks for replying. I happen to have another problem. If i > try to create a new task, no matter what i do i always get the message > > 'KDB: task new: not chief' > > the line im using to create a task is as follows: > recv = l4_task_new(recv, 6, (dword_t) task+(4096*2), (dword_t)task, > L4_NIL_ID); > Where task is a function defined void task(void); Im asuming here that the > stack will begin , lets say to pages from the code page (task + (4096*2)). > > Am i missing something here ?? (-: Yes: In order to be allowed to create or delete a task, you must be the task's ``chief.'' When the system boots, Rmgr (task 4) is the chief of all other tasks, and thus is the only task which may create new tasks. Your task (probably task 5) initially cannot create any task. The current owner of a chief right to nonexistent tasks can transfer the right using the l4_task_new() system call. There is an Rmgr protocol message which allows tasks to request chief rights to specific tasks from Rmgr. I'll append below a library which wraps the Rmgr protocol into C bindings. With it it you can request a new chief right using the sequence: rmgr_init(); error = rmgr_get_task(number); (The library also contains functions called rmgr_task_new() and rmgr_task_new_with_prio() which lets Rmgr create a new task, but these currently don't work with Fiasco because they require long-message IPC. Long-message IPC has only been implemented recently, and I'm currently testing it; it will be included in the next release.) Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: Am i missing something here ?
by kermit the frog 27 Apr '99

27 Apr '99

Yeah, that could be a solution (the loop) but, ass soon as i try to create the new task it dumps the register contents and then asks me if i want to reboot ... i guess ill have to recompile it with a different # and boot to try every new configuration ... Cervi~no Ulises <kermit(a)tower.com.ar> <c-3087-2(a)unrctu.edu.ar> ............................................................................... On Tue, 27 Apr 1999, Gernot Heiser wrote: > >>>>> "ktf" == kermit the frog <kermit(a)tower.com.ar> writes: > > ktf> Well, ive attached the source code of my program. To anser to your > ktf> question, recv is initialized to task=6; ltherad=0; i know that my program > ktf> starts with task=5 so im using the next task available. > > That doesn't guarantee that this task isn't in use (e.g. for a device > driver). I'm not sure how fiasco allocates initial tasks. You'd be > better off running a loop trying all task ids. > > Gernot > -- > Gernot Heiser ,--_|\ School of Computer Sci. & Engin. > Phone: +61 2 9385 5156 / \ The University of NSW > Fax: +61 2 9385 5995 \_,--._* Sydney, Australia 2052 > E-mail: G.Heiser(a)unsw.edu.au v http://www.cse.unsw.edu.au/~gernot > PGP fingerprint: 94 1E B8 28 25 FD 7C 94 20 10 92 E5 0B FF 39 8F >

1 0

Re: Am i missing something here ?
by kermit the frog 27 Apr '99

27 Apr '99

Well, ive attached the source code of my program. To anser to your question, recv is initialized to task=6; ltherad=0; i know that my program starts with task=5 so im using the next task available. Cervi~no Ulises <kermit(a)tower.com.ar> <c-3087-2(a)unrctu.edu.ar> ...............................................................................

1 0

Re: Am i missing something here ?
by Michael Hohmuth 27 Apr '99

27 Apr '99

kermit the frog <kermit(a)tower.com.ar> writes: > Heres the thing, whenever I start 2 or more task/threads that contain some > sort of a 'pause' in the for l4_i386_ipc_receive(L4_NIL_ID ... it seems to > be that all tasks/threads block forever, eventhough they have a TIMEOUT of > 4 secs, sometimes even less. I think you are seeing a bug in the timeout code which I happened to fix last week. Please try the patch appended below. I'll probably also release a new Fiasco snapshot soon. BTW, does anyone think a public CVS repository for Fiasco would be helpful? If so, please email me privately. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Am i missing something here ?
by kermit the frog 26 Apr '99

26 Apr '99

While "testing" some REALLY simple servers that I wrote I noticed something, maybe this is a bug or maybe Im plain dumb and im missing something (-; Heres the thing, whenever I start 2 or more task/threads that contain some sort of a 'pause' in the for l4_i386_ipc_receive(L4_NIL_ID ... it seems to be that all tasks/threads block forever, eventhough they have a TIMEOUT of 4 secs, sometimes even less. Example for 2 tasks: Initialization stuff . . for(;;){ printf("."); /* wait 4 sec */ l4_i386_ipc_receive(L4_NIL_ID, 0, &d1, &d2, L4_IPC_TIMEOUT(0,0,255,8,0,0), &result); } In this example you have 2 tasks which do the same thing, just printf("something"); . Very simple, but they seem to block. The same thing happens if you create a new thread with l4_thread_ex_regs, and you have the same loop (for ... printf ... l4_ipc_recev) in a function, say my_thread, and send &my_thread as the EIP. Well, if you happen to remove those 'pauses' all threads/tasks seem to work just fine (although if youre printing in each of them you cant see anything (-: So thats it. Did anyone had this error ?? Cervi~no Ulises <kermit(a)tower.com.ar> <c-3087-2(a)unrctu.edu.ar> ...............................................................................

1 0

Re: using L4-Linux
by Michael Hohmuth 01 Apr '99

01 Apr '99

edmundo(a)rano.demon.co.uk writes: > I had it sort of running just now ... > [...] > I then had no cursor, but a shell, with which I could walk around the > file system using pwd, cd and echo *. It reboots as soon as I do > anything that involves a fork, such as ls, cat or sh. So I'll worry > about configuring X later, right? :-) > I built main and sigma0 myself under Debian 2.1, i.e. gcc 2.7.2.3 and > binutils 2.9.1.0.19a, from the sources dated 981207. Everything else > was already on grub-ext2fs-floppy from the ftp site. I compile on a > 686 machine and run Fiasco on a 486 machine. I have tried the boot floppy you sent me, and I was able to boot L4Linux into multiuser mode. However, I had to replace "glinux.gz" with my own, self-compiled L4Linux server image because the one on the boot floppy didn't contain drivers for my SCSI card. One thing you might want to try is booting a newer L4Linux binary (the one one your floppy is pretty old). I'll send you mine under separate cover. If this also doesn't work, I guess that Fiasco has a problem with 486s. Right now I cannot test this because I currently don't have a working 486, but I probably will get one the week after the next. Michael PS: I have uploaded a new grub-ext2fs-floppy.gz which contains the newest version of all binaries, including Fiasco and working configuration files. It's at <URL:ftp://ftp.inf.tu-dresden.de/pub/os/L4/devel/grub-ext2fs-floppy.gz>. -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

2 1

Fiasco/OSKit-0.96 patch (was Re: "relocation truncated")
by Michael Hohmuth 27 Mar '99

27 Mar '99

OKUJI Yoshinori <okuji(a)kuicr.kyoto-u.ac.jp> writes: > Thanks for your answer. Could you show the patch you made for newer > OSKit? I'd like to see what changes are needed for different version > of OSKit. I'll append the patch below. You should only use it for informational purposes, and you shouldn't try actually applying it (I pretty sure it doesn't apply cleanly). This patch really only is a quick hack. There are many modifications involving changes to type names and include file names. Fiasco probably should be fixed not to rely on OSKit's type names so religiously. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Jump to page:

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