Re: [9fans] drawterm and linux 2.4.4 SMP

Re: [9fans] drawterm and linux 2.4.4 SMP

[forsyth]

>>Pthreads are just fine for doing drawterm, they're just no good for
>>doing Inferno emu.

possibly, since the signalling problem doesn't arise,
but having looked at the pthreads implementation again recently
to see how it does it -- it's frightening to wade through it --
i'd still do it myself for something like drawterm that i might care about.
there's no real mystery.

Re: [9fans] drawterm and linux 2.4.4 SMP

[David Gordon Hogan]

> If my tuits are round enough,

Have you tried getting an n-gon tuit, where n is large?

Re: [9fans] drawterm and linux 2.4.4 SMP

[Colin DeVilbiss]

> Thanks in advance for any help.

Thanks now post-ex for everbody's help and comments: for the moment,
pthreads drawterm is working just fine.  If my tuits are round enough,
I may see about finding the correct Linux-native solution at some point,
but this will get me by quite fashionably in the meantime.

Have a great weekend, everyone.

--
Colin DeVilbiss
crdevilb@mtu.edu

Re: [9fans] drawterm and linux 2.4.4 SMP

[nigel]

[-- Attachment #1: Type: text/plain, Size: 91 bytes --]

Pthreads are just fine for doing drawterm, they're just no good for
doing Inferno emu.


[-- Attachment #2: Type: message/rfc822, Size: 4445 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 161 bytes --]

the pthreads implementations had several problems when we
tried to use them for inferno, so we stopped banging our heads
against them and did it ourselves.


[-- Attachment #2.1.2: Type: message/rfc822, Size: 2883 bytes --]

From: "William K. Josephson" <wkj@eecs.harvard.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] drawterm and linux 2.4.4 SMP
Date: Sat, 21 Jul 2001 00:59:32 -0400
Message-ID: <20010721005932.A42689@honk.eecs.harvard.edu>

On Fri, Jul 20, 2001 at 10:38:30PM -0400, jmk@plan9.bell-labs.com wrote:
> On Fri Jul 20 21:16:24 EDT 2001, crdevilb@mtu.edu wrote:
> > Was there some suggestion or patch anybody had to fix this, or am I
> > going to be digging into the linux kernel to find yet another hack to
> > solve this?

> I haven't looked at that code but from the description it looks like
> the thread switch hack Phil Winterbottom and I did when we ported Inferno
> to Linux a very long time ago. At that time Linux used the task

I haven't looked at the drawterm code in quite a while, but I'd
suggest using the pthreads version.  I'm fairly sure that that is what
is done under FreeBSD instead of using their rfork(2) (or the new libc
wrapper in 4.3-stable).  The pthreads implementation for Linux is a
good example of how not to use #ifdef (or it was last I looked), but
in general the implementations I've seen appear to be compatible and
stable enough to use on almost all the major Unix derivatives that
mucking around with the tss stuff probably isn't worth it for
something like drawterm.  Especially when the kernel changes as often
as it does under Linux.

 -WJ

Re: [9fans] drawterm and linux 2.4.4 SMP

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 161 bytes --]

the pthreads implementations had several problems when we
tried to use them for inferno, so we stopped banging our heads
against them and did it ourselves.


[-- Attachment #2: Type: message/rfc822, Size: 2883 bytes --]

From: "William K. Josephson" <wkj@eecs.harvard.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] drawterm and linux 2.4.4 SMP
Date: Sat, 21 Jul 2001 00:59:32 -0400
Message-ID: <20010721005932.A42689@honk.eecs.harvard.edu>

On Fri, Jul 20, 2001 at 10:38:30PM -0400, jmk@plan9.bell-labs.com wrote:
> On Fri Jul 20 21:16:24 EDT 2001, crdevilb@mtu.edu wrote:
> > Was there some suggestion or patch anybody had to fix this, or am I
> > going to be digging into the linux kernel to find yet another hack to
> > solve this?

> I haven't looked at that code but from the description it looks like
> the thread switch hack Phil Winterbottom and I did when we ported Inferno
> to Linux a very long time ago. At that time Linux used the task

I haven't looked at the drawterm code in quite a while, but I'd
suggest using the pthreads version.  I'm fairly sure that that is what
is done under FreeBSD instead of using their rfork(2) (or the new libc
wrapper in 4.3-stable).  The pthreads implementation for Linux is a
good example of how not to use #ifdef (or it was last I looked), but
in general the implementations I've seen appear to be compatible and
stable enough to use on almost all the major Unix derivatives that
mucking around with the tss stuff probably isn't worth it for
something like drawterm.  Especially when the kernel changes as often
as it does under Linux.

 -WJ

Re: [9fans] drawterm and linux 2.4.4 SMP

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 97 bytes --]

we changed inferno to avoid using the tss register.
the same thing should work for drawterm.


[-- Attachment #2: Type: message/rfc822, Size: 3008 bytes --]

From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] drawterm and linux 2.4.4 SMP
Date: Fri, 20 Jul 2001 22:38:30 -0400
Message-ID: <20010721023834.60B961998A@mail.cse.psu.edu>

On Fri Jul 20 21:16:24 EDT 2001, crdevilb@mtu.edu wrote:
> I remember there was talk on the list some time ago about drawterm for
> linux and how it may very well be broken under linux 2.4; well, that
> time is here.  It seems (to me) that it is broken because I was just
> stepping through the source (because it was SEGVing), and the macro CT
> (at linux.c:30) seems to nondeterministically alternate between giving
> the right answer and giving NULL, because linux.c:/^gettss(void)
> nondeterministically alternates between returning 6 and 8...
>
> Was there some suggestion or patch anybody had to fix this, or am I
> going to be digging into the linux kernel to find yet another hack to
> solve this?
>
> Thanks in advance for any help.
>
> --
> Colin DeVilbiss
> crdevilb@mtu.edu

I haven't looked at that code but from the description it looks like
the thread switch hack Phil Winterbottom and I did when we ported Inferno
to Linux a very long time ago. At that time Linux used the task
switch capabililty of the x86 (why, I don't know) so it was possible
to use the contents of the task-switch register as an index to find the process
context in the shared memory as there was no other private per-process
memory available (Plan 9 at least gives each process a private stack).

You will need to find some other way to do it, but it will probably be
just as much of a hack. I don't know what possibilities there are under
Linux 2.4, but they must surely have added something (that could be used).
Perhaps someone who is more familiar with both the thread-switching
scheme used in drawterm and Linux can give a better answer.

Re: [9fans] drawterm and linux 2.4.4 SMP

[William K. Josephson]

On Fri, Jul 20, 2001 at 10:38:30PM -0400, jmk@plan9.bell-labs.com wrote:
> On Fri Jul 20 21:16:24 EDT 2001, crdevilb@mtu.edu wrote:
> > Was there some suggestion or patch anybody had to fix this, or am I
> > going to be digging into the linux kernel to find yet another hack to
> > solve this?

> I haven't looked at that code but from the description it looks like
> the thread switch hack Phil Winterbottom and I did when we ported Inferno
> to Linux a very long time ago. At that time Linux used the task

I haven't looked at the drawterm code in quite a while, but I'd
suggest using the pthreads version.  I'm fairly sure that that is what
is done under FreeBSD instead of using their rfork(2) (or the new libc
wrapper in 4.3-stable).  The pthreads implementation for Linux is a
good example of how not to use #ifdef (or it was last I looked), but
in general the implementations I've seen appear to be compatible and
stable enough to use on almost all the major Unix derivatives that
mucking around with the tss stuff probably isn't worth it for
something like drawterm.  Especially when the kernel changes as often
as it does under Linux.

 -WJ

Re: [9fans] drawterm and linux 2.4.4 SMP

[Ish Rattan]

Linux kernel-2.4.3
Glibc-2.2.2

----mkfile-Linux---
WIN=x11
OS=posix

CC=cc
CFLAGS=-g -c -DLINUX -I/usr/X11R6/include
TARG=drawterm
O=o
LD=cc
LDFLAGS=-g -static -o drawterm

DEVIP=devip-unix
DEVFS=devunixfs
OSFILES=md-iprint.$O canlock-x86-gcc.$O
LIBS=-lpthread -lm -L/usr/X11R6/lib -lX11

ml-%.$O:	$DSRC/libmemlayer/%.c
	$CC $CFLAGS -o ml-$stem.o $DSRC/libmemlayer/$stem.c

md-%.$O:	$DSRC/libmemdraw/%.c
	$CC $CFLAGS -o md-$stem.o $DSRC/libmemdraw/$stem.c

d-%.$O:	$DSRC/libdraw/%.c
	$CC $CFLAGS -o d-$stem.o $DSRC/libdraw/$stem.c

------

Re: [9fans] drawterm and linux 2.4.4 SMP

[Ish Rattan]

It compiles correctly if you use POSIX threads from glibc-2.2. Makefile
is now almost similar to the one for FreeBSD (POSIX thread version). I
have the it on another machine will post asap.

-hth

On Sat, 21 Jul 2001 crdevilb@mtu.edu wrote:

> I remember there was talk on the list some time ago about drawterm for
> linux and how it may very well be broken under linux 2.4; well, that
> time is here.  It seems (to me) that it is broken because I was just
> stepping through the source (because it was SEGVing), and the macro CT
> (at linux.c:30) seems to nondeterministically alternate between giving
> the right answer and giving NULL, because linux.c:/^gettss(void)
> nondeterministically alternates between returning 6 and 8...
>
> Was there some suggestion or patch anybody had to fix this, or am I
> going to be digging into the linux kernel to find yet another hack to
> solve this?
>
> Thanks in advance for any help.
>
>

Re: [9fans] drawterm and linux 2.4.4 SMP

[Alexander Viro]

On Sat, 21 Jul 2001 crdevilb@mtu.edu wrote:

> Was there some suggestion or patch anybody had to fix this, or am I
> going to be digging into the linux kernel to find yet another hack to
> solve this?

Check the archives.

BTW, there _is_ a dirty hack that will work on slightly modified 2.4 (x86).
So if you are into really kinky stuff - try to play with the following
idea: let sys_fork() and sys_clone() set cr2 to current->pid before returning
into (child's) userland. Ditto on the exit from do_page_fault(). Then you are
guaranteed that in userland cr2 will be always equal to value of getpid(2).

Mechanics behind this ugliness:
	a) cr2 is never directly assigned - neither by kernel nor by userland
	b) it is clobbered by pagefault exception (MMU sets it to address that
had caused fault)
	c) pagefault handler reads its value in the very beginning and doesn't
use cr2 after that.

IIRC, that had been proposed as a proof-of-concept implementation of
getpid() without syscalls. It should even be 'portable' to other systems
running on x86 - e.g. in case of Plan 9 you'd need to s/current/up/ and
s/do_page_fault/fault386/. ISTR author of that hack claiming that other
architectures usually allow something similar - rarely used registers
that are clobbered only in situations when we have access to task_struct
and know that thing had been clobbered.

IMO it's a dirty hack, but then so was the use of TSS...

/me grabs the popcorn and removes Boyd from killfile for a while...

Re: [9fans] drawterm and linux 2.4.4 SMP

[jmk]

On Fri Jul 20 21:16:24 EDT 2001, crdevilb@mtu.edu wrote:
> I remember there was talk on the list some time ago about drawterm for
> linux and how it may very well be broken under linux 2.4; well, that
> time is here.  It seems (to me) that it is broken because I was just
> stepping through the source (because it was SEGVing), and the macro CT
> (at linux.c:30) seems to nondeterministically alternate between giving
> the right answer and giving NULL, because linux.c:/^gettss(void)
> nondeterministically alternates between returning 6 and 8...
>
> Was there some suggestion or patch anybody had to fix this, or am I
> going to be digging into the linux kernel to find yet another hack to
> solve this?
>
> Thanks in advance for any help.
>
> --
> Colin DeVilbiss
> crdevilb@mtu.edu

I haven't looked at that code but from the description it looks like
the thread switch hack Phil Winterbottom and I did when we ported Inferno
to Linux a very long time ago. At that time Linux used the task
switch capabililty of the x86 (why, I don't know) so it was possible
to use the contents of the task-switch register as an index to find the process
context in the shared memory as there was no other private per-process
memory available (Plan 9 at least gives each process a private stack).

You will need to find some other way to do it, but it will probably be
just as much of a hack. I don't know what possibilities there are under
Linux 2.4, but they must surely have added something (that could be used).
Perhaps someone who is more familiar with both the thread-switching
scheme used in drawterm and Linux can give a better answer.

[9fans] drawterm and linux 2.4.4 SMP

[crdevilb]

I remember there was talk on the list some time ago about drawterm for
linux and how it may very well be broken under linux 2.4; well, that
time is here.  It seems (to me) that it is broken because I was just
stepping through the source (because it was SEGVing), and the macro CT
(at linux.c:30) seems to nondeterministically alternate between giving
the right answer and giving NULL, because linux.c:/^gettss(void)
nondeterministically alternates between returning 6 and 8...

Was there some suggestion or patch anybody had to fix this, or am I
going to be digging into the linux kernel to find yet another hack to
solve this?

Thanks in advance for any help.

--
Colin DeVilbiss
crdevilb@mtu.edu