After my main function has exited, the task still seems to live. On the serial debug console I see: myapp | Main function exit with code 0
but pressing N at the cmd prompt console shows: 1E.00 myapp.rm 1E.01 myapp.sem 1E.02 myapp.main
and every time I run my app another instance appears... Is there anything I am supposed to do to make the task go away properly? I am running simple_ts and events, and my app is a l4env_freebsd app compiled in DROPS and running in the fiasco kernel. Let me know if I need to supply further information.
On Thu Jun 30, 2005 at 11:32:12 +0200, Bert van Leeuwen wrote:
After my main function has exited, the task still seems to live. On the serial debug console I see: myapp | Main function exit with code 0
but pressing N at the cmd prompt console shows: 1E.00 myapp.rm 1E.01 myapp.sem 1E.02 myapp.main
and every time I run my app another instance appears... Is there anything I am supposed to do to make the task go away properly? I am running simple_ts and events, and my app is a l4env_freebsd app compiled in DROPS and running in the fiasco kernel. Let me know if I need to supply further information.
If you're using events deregistering names should work. Do you start names with the --events option?
Adam
I didn't have --events, but I tried that now, and still doesn't make a difference. names says this when it starts up: names | Fiasco detected, registering thread names at kernel names | Starting thread listening for `exit' events
but other than that the behaviour remains as before. I will check to see if my names and events are up to date with the CVS versions, mine are probably around 3-4 months old now.
On 6/30/05, Adam Lackorzynski adam@os.inf.tu-dresden.de wrote:
On Thu Jun 30, 2005 at 11:32:12 +0200, Bert van Leeuwen wrote:
After my main function has exited, the task still seems to live. On the serial debug console I see: myapp | Main function exit with code 0
but pressing N at the cmd prompt console shows: 1E.00 myapp.rm 1E.01 myapp.sem 1E.02 myapp.main
and every time I run my app another instance appears... Is there anything I am supposed to do to make the task go away properly?
I
am running simple_ts and events, and my app is a l4env_freebsd app
compiled
in DROPS and running in the fiasco kernel. Let me know if I need to
supply
further information.
If you're using events deregistering names should work. Do you start names with the --events option?
Adam
Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
On Thu Jun 30, 2005 at 17:10:16 +0200, Bert van Leeuwen wrote:
I didn't have --events, but I tried that now, and still doesn't make a difference. names says this when it starts up: names | Fiasco detected, registering thread names at kernel names | Starting thread listening for `exit' events
but other than that the behaviour remains as before. I will check to see if my names and events are up to date with the CVS versions, mine are probably around 3-4 months old now.
Good, do that.
Additionally, add --events arguments to dm_phys, simple_ts, loader and con.
Adam
Thanks for the help, will try all the above. I updated my names from CVS, but it doesn't compile/link, so I'll probably have to update a bunch of other stuff too.
/home/bert/DROPS/l4/pkg/names/server/src/names.c: In function `main': /home/bert/DROPS/l4/pkg/names/server/src/names.c:440: warning: implicit declaration of function `l4util_kip_kernel_has_feature' ... Compiling predefined.o ... Compiling events.o ... Compiling names-server.o ==> Linking names names.o(.text+0x615): In function `main': /home/bert/DROPS/l4/pkg/names/server/src/names.c:440: undefined reference to `l4util_kip_kernel_has_feature' collect2: ld returned 1 exit status
On 6/30/05, Adam Lackorzynski adam@os.inf.tu-dresden.de wrote:
On Thu Jun 30, 2005 at 17:10:16 +0200, Bert van Leeuwen wrote:
I didn't have --events, but I tried that now, and still doesn't make a difference. names says this when it starts up: names | Fiasco detected, registering thread names at kernel names | Starting thread listening for `exit' events
but other than that the behaviour remains as before. I will check to see
if
my names and events are up to date with the CVS versions, mine are
probably
around 3-4 months old now.
Good, do that.
Additionally, add --events arguments to dm_phys, simple_ts, loader and con.
Adam
Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
On Thu Jun 30, 2005 at 17:52:11 +0200, Bert van Leeuwen wrote:
Thanks for the help, will try all the above. I updated my names from CVS, but it doesn't compile/link, so I'll probably have to update a bunch of other stuff too.
Yep, but that shouldn't harm.
Adam
l4-hackers@os.inf.tu-dresden.de