linux-um archives
 help / color / mirror / Atom feed
* [uml-devel] [Patch 1/1] uml: fix uml-use-sysemu-for-tt.patch
@ 2004-11-12 14:10 Bodo Stroesser
  2004-11-13  7:54 ` Blaisorblade
  0 siblings, 1 reply; 6+ messages in thread
From: Bodo Stroesser @ 2004-11-12 14:10 UTC (permalink / raw)
  To: BlaisorBlade; +Cc: Jeff Dike, User-mode Linux Kernel Development

From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>

The patch needs some small corrections:
1) local_using_sysemu must be sampled *before* the next
    ptrace(PTRACE_SYSEMU/SYSCALL) and must stay the same until do_syscall()
    has been done. Currently it is sampled before do_syscall() and is used
    after this for ptrace(PTRACE_SYSEMU/SYSCALL). Even if no problem is
    visible to the UML user, a single syscall could be executed on the host
    when switching on sysemu. The result of this then is overwritten by the
    syscall execution in UML.
    Since the first event the tracer has to handle is not a syscall, it's
    enough to initialize local_using_sysemu to 0;
2) Even if the host never *does* a syscall in SYSEMU, we have to write the
    syscall number with -1, to not have the host doing syscall restarting.
    This would happen only with an invalid syscall number equal to one of
    the -ERESTART values. But to be perfect ...
Additionally I changed do_syscall() to be void instead of int.

Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
---

--- a/arch/um/kernel/tt/include/tt.h	2004-11-11 21:27:08.405134680 +0100
+++ b/arch/um/kernel/tt/include/tt.h	2004-11-11 21:27:23.807793120 +0100
@@ -26,7 +26,7 @@ extern void set_tracing(void *t, int tra
  extern int is_tracing(void *task);
  extern void syscall_handler(int sig, union uml_pt_regs *regs);
  extern void exit_kernel(int pid, void *task);
-extern int do_syscall(void *task, int pid, int local_using_sysemu);
+extern void do_syscall(void *task, int pid, int local_using_sysemu);
  extern void do_sigtrap(void *task);
  extern int is_valid_pid(int pid);
  extern void remap_data(void *segment_start, void *segment_end, int w);
--- a/arch/um/kernel/tt/tracer.c	2004-11-12 10:28:46.776498528 +0100
+++ a/arch/um/kernel/tt/tracer.c	2004-11-12 10:34:41.381590360 +0100
@@ -186,7 +186,7 @@ int tracer(int (*init_proc)(void *), voi
  	unsigned long eip = 0;
  	int status, pid = 0, sig = 0, cont_type, tracing = 0, op = 0;
  	int last_index, proc_id = 0, n, err, old_tracing = 0, strace = 0;
-	int pt_syscall_parm, local_using_sysemu;
+	int pt_syscall_parm, local_using_sysemu = 0;

  	signal(SIGPIPE, SIG_IGN);
  	setup_tracer_winch();
@@ -305,9 +305,6 @@ int tracer(int (*init_proc)(void *), voi
  			if ( tracing ) /* Assume: no syscall, when coming from user */
  				do_sigtrap(task);

-			local_using_sysemu = get_using_sysemu();
-			pt_syscall_parm = local_using_sysemu ? PTRACE_SYSEMU : PTRACE_SYSCALL;
-
  			switch(sig){
  			case SIGUSR1:
  				sig = 0;
@@ -385,6 +382,9 @@ int tracer(int (*init_proc)(void *), voi
  				continue;
  			}

+			local_using_sysemu = get_using_sysemu();
+			pt_syscall_parm = local_using_sysemu ? PTRACE_SYSEMU : PTRACE_SYSCALL;
+
  			if(tracing){
  				if(singlestepping(task))
  					cont_type = PTRACE_SINGLESTEP;
--- a/arch/um/kernel/tt/syscall_user.c	2004-11-12 10:30:32.181474536 +0100
+++ b/arch/um/kernel/tt/syscall_user.c	2004-11-12 10:41:04.146401264 +0100
@@ -48,7 +48,7 @@ void do_sigtrap(void *task)
  	UPT_SYSCALL_NR(TASK_REGS(task)) = -1;
  }

-int do_syscall(void *task, int pid, int local_using_sysemu)
+void do_syscall(void *task, int pid, int local_using_sysemu)
  {
  	unsigned long proc_regs[FRAME_SIZE];

@@ -61,14 +61,11 @@ int do_syscall(void *task, int pid, int
  	   ((unsigned long *) PT_IP(proc_regs) <= &_etext))
  		tracer_panic("I'm tracing myself and I can't get out");

-	if(local_using_sysemu)
-		return(1);
-
+	/* syscall number -1 in sysemu skips syscall restarting in host */
  	if(ptrace(PTRACE_POKEUSER, pid, PT_SYSCALL_NR_OFFSET,
-		  __NR_getpid) < 0)
+		  local_using_sysemu ? -1 : __NR_getpid) < 0)
  		tracer_panic("do_syscall : Nullifying syscall failed, "
  			     "errno = %d", errno);
-	return(1);
  }

  /*



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [uml-devel] [Patch 1/1] uml: fix uml-use-sysemu-for-tt.patch
  2004-11-12 14:10 [uml-devel] [Patch 1/1] uml: fix uml-use-sysemu-for-tt.patch Bodo Stroesser
@ 2004-11-13  7:54 ` Blaisorblade
  2004-11-15 19:04   ` Bodo Stroesser
  0 siblings, 1 reply; 6+ messages in thread
From: Blaisorblade @ 2004-11-13  7:54 UTC (permalink / raw)
  To: user-mode-linux-devel; +Cc: Bodo Stroesser, Jeff Dike

On Friday 12 November 2004 15:10, Bodo Stroesser wrote:
> From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
>
> The patch needs some small corrections:
> 1) local_using_sysemu must be sampled *before* the next
>     ptrace(PTRACE_SYSEMU/SYSCALL) and must stay the same until do_syscall()
>     has been done. Currently it is sampled before do_syscall() and is used
>     after this for ptrace(PTRACE_SYSEMU/SYSCALL). Even if no problem is
>     visible to the UML user, a single syscall could be executed on the host
>     when switching on sysemu. The result of this then is overwritten by the
>     syscall execution in UML.

>     Since the first event the tracer has to handle is not a syscall, it's
>     enough to initialize local_using_sysemu to 0;

Sorry, what happens if the first signal it gets is a SIGTRAP, and so 
local_using_sysemu is not yet set? If this is impossible, please add a 
comment in the code for this. However, it seems that it can get to the 
SIGTRAP case with tracing == 1. When beginning the procedure, it is 0, but it 
can be changed with the value from is_tracing(task). I've not checked if that 
is zeroed on process creation (i.e. by do_fork() calling copy_thread()), but 
just note that in the code.

> 2) Even if the host never *does* a syscall in SYSEMU, we have to write the
>     syscall number with -1, to not have the host doing syscall restarting.
>     This would happen only with an invalid syscall number equal to one of
>     the -ERESTART values.

>     But to be perfect ... 

Yes, but shouldn't this be handled on the host? Restarting a syscall which has 
never been done does not seem something that SYSEMU should allow... I don't 
want anybody to need going through the code and checking that this is safe.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [uml-devel] [Patch 1/1] uml: fix uml-use-sysemu-for-tt.patch
  2004-11-13  7:54 ` Blaisorblade
@ 2004-11-15 19:04   ` Bodo Stroesser
  2004-11-15 20:10     ` Blaisorblade
  2004-11-26  2:39     ` Blaisorblade
  0 siblings, 2 replies; 6+ messages in thread
From: Bodo Stroesser @ 2004-11-15 19:04 UTC (permalink / raw)
  To: Blaisorblade; +Cc: user-mode-linux-devel, Jeff Dike

Blaisorblade wrote:
> On Friday 12 November 2004 15:10, Bodo Stroesser wrote:
> 
>>From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
>>
>>The patch needs some small corrections:
>>1) local_using_sysemu must be sampled *before* the next
>>    ptrace(PTRACE_SYSEMU/SYSCALL) and must stay the same until do_syscall()
>>    has been done. Currently it is sampled before do_syscall() and is used
>>    after this for ptrace(PTRACE_SYSEMU/SYSCALL). Even if no problem is
>>    visible to the UML user, a single syscall could be executed on the host
>>    when switching on sysemu. The result of this then is overwritten by the
>>    syscall execution in UML.
> 
> 
>>    Since the first event the tracer has to handle is not a syscall, it's
>>    enough to initialize local_using_sysemu to 0;
> 
> 
> Sorry, what happens if the first signal it gets is a SIGTRAP, and so 
> local_using_sysemu is not yet set? If this is impossible, please add a 
> comment in the code for this. However, it seems that it can get to the 
> SIGTRAP case with tracing == 1. When beginning the procedure, it is 0, but it 
> can be changed with the value from is_tracing(task). I've not checked if that 
> is zeroed on process creation (i.e. by do_fork() calling copy_thread()), but 
> just note that in the code.
OK: Let's summarize:
1) tracer() is started exactly once.
2) The first this it does, is starting the first ptraced-process via clone().
3) Then it waits until the new process stops.
4) Since the process will run start_kernel() in kernel space, it is resumed
    with PTRACE_CONT.
Thus, before having any syscall interception, the process has to stop itself
with a SIGUSR1, giving the tracer an OP_TRACE_OP request. After this
local_using_sysemu will be set and the process will be resumed with
PTRACE_SYSCALL or PTRACE_SYSEMU.
> 
> 
>>2) Even if the host never *does* a syscall in SYSEMU, we have to write the
>>    syscall number with -1, to not have the host doing syscall restarting.
>>    This would happen only with an invalid syscall number equal to one of
>>    the -ERESTART values.
> 
> 
>>    But to be perfect ... 
> 
> 
> Yes, but shouldn't this be handled on the host? Restarting a syscall which has 
> never been done does not seem something that SYSEMU should allow... I don't 
> want anybody to need going through the code and checking that this is safe.
Yes. It should. So I exactly added this to the "advanced sysemu". But despite this
UML should work on an older sysemu host, too. So I add this now, and with the
SYSEMU_SINGLESTEP-patches a skip of writing -1 is inserted, if the new sysemu is
in use.


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [uml-devel] [Patch 1/1] uml: fix uml-use-sysemu-for-tt.patch
  2004-11-15 19:04   ` Bodo Stroesser
@ 2004-11-15 20:10     ` Blaisorblade
  2004-11-16  9:18       ` Bodo Stroesser
  2004-11-26  2:39     ` Blaisorblade
  1 sibling, 1 reply; 6+ messages in thread
From: Blaisorblade @ 2004-11-15 20:10 UTC (permalink / raw)
  To: Bodo Stroesser; +Cc: user-mode-linux-devel, Jeff Dike

On Monday 15 November 2004 20:04, Bodo Stroesser wrote:
> Blaisorblade wrote:
> > On Friday 12 November 2004 15:10, Bodo Stroesser wrote:
> >>From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
> >>
> >>The patch needs some small corrections:
> >>1) local_using_sysemu must be sampled *before* the next
> >>    ptrace(PTRACE_SYSEMU/SYSCALL) and must stay the same until
> >> do_syscall() has been done. Currently it is sampled before do_syscall()
> >> and is used after this for ptrace(PTRACE_SYSEMU/SYSCALL). Even if no
> >> problem is visible to the UML user, a single syscall could be executed
> >> on the host when switching on sysemu. The result of this then is
> >> overwritten by the syscall execution in UML.

> >>    Since the first event the tracer has to handle is not a syscall, it's
> >>    enough to initialize local_using_sysemu to 0;

> > Sorry, what happens if the first signal it gets is a SIGTRAP, and so
> > local_using_sysemu is not yet set? If this is impossible, please add a
> > comment in the code for this. However, it seems that it can get to the
> > SIGTRAP case with tracing == 1. When beginning the procedure, it is 0,
> > but it can be changed with the value from is_tracing(task). I've not
> > checked if that is zeroed on process creation (i.e. by do_fork() calling
> > copy_thread()), but just note that in the code.

> OK: Let's summarize:
> 1) tracer() is started exactly once.
> 2) The first this it does, is starting the first ptraced-process via
> clone(). 3) Then it waits until the new process stops.
> 4) Since the process will run start_kernel() in kernel space, it is resumed
>     with PTRACE_CONT.
> Thus, before having any syscall interception, the process has to stop
> itself with a SIGUSR1, giving the tracer an OP_TRACE_OP request. After this
> local_using_sysemu will be set and the process will be resumed with
> PTRACE_SYSCALL or PTRACE_SYSEMU.

> >>2) Even if the host never *does* a syscall in SYSEMU, we have to write
> >> the syscall number with -1, to not have the host doing syscall
> >> restarting. This would happen only with an invalid syscall number equal
> >> to one of the -ERESTART values.
> >>
> >>
> >>    But to be perfect ...

> > Yes, but shouldn't this be handled on the host? Restarting a syscall
> > which has never been done does not seem something that SYSEMU should
> > allow... I don't want anybody to need going through the code and checking
> > that this is safe.

> Yes. It should. So I exactly added this to the "advanced sysemu". But
> despite this UML should work on an older sysemu host, too. So I add this
> now, and with the SYSEMU_SINGLESTEP-patches a skip of writing -1 is
> inserted, if the new sysemu is in use.
Hmm - not yet had time to get near that (I'm busy), however if 
SYSEMU_SINGLESTEP fixes this API inconsistency, the old SYSEMU API will 
probably not be accepted by mainline developers, not it should be sent by us 
- remember that we want to try merging SYSEMU sooner than SKAS4.

No single UML (except some ones using the sysemu incremental version, which we 
don't want to support) is unable to run without SYSEMU, so dropping that 
support should be ok.

Also, this new mode must wait for now - get some time to test it, I'll do the 
same when I've time. Currently I have too few time.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [uml-devel] [Patch 1/1] uml: fix uml-use-sysemu-for-tt.patch
  2004-11-15 20:10     ` Blaisorblade
@ 2004-11-16  9:18       ` Bodo Stroesser
  0 siblings, 0 replies; 6+ messages in thread
From: Bodo Stroesser @ 2004-11-16  9:18 UTC (permalink / raw)
  To: Blaisorblade; +Cc: user-mode-linux-devel, Jeff Dike

Blaisorblade wrote:
> On Monday 15 November 2004 20:04, Bodo Stroesser wrote:
> 
>>Blaisorblade wrote:
>>
>>>On Friday 12 November 2004 15:10, Bodo Stroesser wrote:
>>>
>>>>From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
>>>>
>>>>The patch needs some small corrections:
>>>>1) local_using_sysemu must be sampled *before* the next
>>>>   ptrace(PTRACE_SYSEMU/SYSCALL) and must stay the same until
>>>>do_syscall() has been done. Currently it is sampled before do_syscall()
>>>>and is used after this for ptrace(PTRACE_SYSEMU/SYSCALL). Even if no
>>>>problem is visible to the UML user, a single syscall could be executed
>>>>on the host when switching on sysemu. The result of this then is
>>>>overwritten by the syscall execution in UML.
> 
> 
>>>>   Since the first event the tracer has to handle is not a syscall, it's
>>>>   enough to initialize local_using_sysemu to 0;
> 
> 
>>>Sorry, what happens if the first signal it gets is a SIGTRAP, and so
>>>local_using_sysemu is not yet set? If this is impossible, please add a
>>>comment in the code for this. However, it seems that it can get to the
>>>SIGTRAP case with tracing == 1. When beginning the procedure, it is 0,
>>>but it can be changed with the value from is_tracing(task). I've not
>>>checked if that is zeroed on process creation (i.e. by do_fork() calling
>>>copy_thread()), but just note that in the code.
> 
> 
>>OK: Let's summarize:
>>1) tracer() is started exactly once.
>>2) The first this it does, is starting the first ptraced-process via
>>clone(). 3) Then it waits until the new process stops.
>>4) Since the process will run start_kernel() in kernel space, it is resumed
>>    with PTRACE_CONT.
>>Thus, before having any syscall interception, the process has to stop
>>itself with a SIGUSR1, giving the tracer an OP_TRACE_OP request. After this
>>local_using_sysemu will be set and the process will be resumed with
>>PTRACE_SYSCALL or PTRACE_SYSEMU.
> 
> 
>>>>2) Even if the host never *does* a syscall in SYSEMU, we have to write
>>>>the syscall number with -1, to not have the host doing syscall
>>>>restarting. This would happen only with an invalid syscall number equal
>>>>to one of the -ERESTART values.
>>>>
>>>>
>>>>   But to be perfect ...
> 
> 
>>>Yes, but shouldn't this be handled on the host? Restarting a syscall
>>>which has never been done does not seem something that SYSEMU should
>>>allow... I don't want anybody to need going through the code and checking
>>>that this is safe.
> 
> 
>>Yes. It should. So I exactly added this to the "advanced sysemu". But
>>despite this UML should work on an older sysemu host, too. So I add this
>>now, and with the SYSEMU_SINGLESTEP-patches a skip of writing -1 is
>>inserted, if the new sysemu is in use.
> 
> Hmm - not yet had time to get near that (I'm busy), however if 
> SYSEMU_SINGLESTEP fixes this API inconsistency, the old SYSEMU API will 
> probably not be accepted by mainline developers, not it should be sent by us 
> - remember that we want to try merging SYSEMU sooner than SKAS4.
> 
> No single UML (except some ones using the sysemu incremental version, which we 
> don't want to support) is unable to run without SYSEMU, so dropping that 
> support should be ok.
> 
> Also, this new mode must wait for now - get some time to test it, I'll do the 
> same when I've time. Currently I have too few time.
No problem. I already tested a lot. But it should be tested *very* well, before
creating a new SKAS3 version from it.
I'm planning this to be the first version that is supported by s390-host!


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [uml-devel] [Patch 1/1] uml: fix uml-use-sysemu-for-tt.patch
  2004-11-15 19:04   ` Bodo Stroesser
  2004-11-15 20:10     ` Blaisorblade
@ 2004-11-26  2:39     ` Blaisorblade
  1 sibling, 0 replies; 6+ messages in thread
From: Blaisorblade @ 2004-11-26  2:39 UTC (permalink / raw)
  To: user-mode-linux-devel; +Cc: Bodo Stroesser, Jeff Dike

OK, now finally I went studying the patch.

On Monday 15 November 2004 20:04, Bodo Stroesser wrote:
> Blaisorblade wrote:
> > On Friday 12 November 2004 15:10, Bodo Stroesser wrote:
> >>From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
> >>
> >>The patch needs some small corrections:
> >>1) local_using_sysemu must be sampled *before* the next
> >>    ptrace(PTRACE_SYSEMU/SYSCALL) and must stay the same until
> >> do_syscall() has been done. Currently it is sampled before do_syscall()
> >> and is used after this for ptrace(PTRACE_SYSEMU/SYSCALL).

Ok, now I went analizing the code and what you say is correct. In fact, when 
merging this I just threw in Jeff Dike's incremental. However, to be correct, 
I must say that in his tree /proc/sysemu was never introduced, so his tree 
was correct.

> >> Even if no 
> >> problem is visible to the UML user, a single syscall could be executed
> >> on the host when switching on sysemu. The result of this then is
> >> overwritten by the syscall execution in UML.

> >>    Since the first event the tracer has to handle is not a syscall, it's
> >>    enough to initialize local_using_sysemu to 0;
> >
> > Sorry, what happens if the first signal it gets is a SIGTRAP, and so
> > local_using_sysemu is not yet set? If this is impossible, please add a
> > comment in the code for this. However, it seems that it can get to the
> > SIGTRAP case with tracing == 1. When beginning the procedure, it is 0,
> > but it can be changed with the value from is_tracing(task). I've not
> > checked if that is zeroed on process creation (i.e. by do_fork() calling
> > copy_thread()), but just note that in the code.

> OK: Let's summarize:
> 1) tracer() is started exactly once.
> 2) The first this it does, is starting the first ptraced-process via
> clone(). 3) Then it waits until the new process stops.
> 4) Since the process will run start_kernel() in kernel space, it is resumed
>     with PTRACE_CONT.

And it has its is_tracing() set to 0 when it is in kernel mode.
> Thus,
(I've filled in the actual reasoning below).
> before having any syscall interception,
it needs to get is_tracing() set to 1, so
> the process has to stop  
> itself with a SIGUSR1, giving the tracer an OP_TRACE_OP request.
Ok.

> After this 
> local_using_sysemu will be set and the process will be resumed with
> PTRACE_SYSCALL or PTRACE_SYSEMU.

So, agreed. Yet, for now I'm still disabling TT SYSEMU in the -bb tree, just 
in case anything else comes up (it does not give a big advantage anyway).

I'm also going to merge this in 2.4-bs
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2004-11-26  2:37 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-12 14:10 [uml-devel] [Patch 1/1] uml: fix uml-use-sysemu-for-tt.patch Bodo Stroesser
2004-11-13  7:54 ` Blaisorblade
2004-11-15 19:04   ` Bodo Stroesser
2004-11-15 20:10     ` Blaisorblade
2004-11-16  9:18       ` Bodo Stroesser
2004-11-26  2:39     ` Blaisorblade

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox