[403] in Pthreads mailing list archive
Re: Booting 2.0.18 on userland easy.nfs.root-4.tar
daemon@ATHENA.MIT.EDU (Pete Delaney)
Mon Sep 9 03:42:30 1996
Date: Mon, 9 Sep 1996 00:06:22 -0700
From: Pete Delaney <Pete.Delaney@RockyMountain.rahul.net>
To: miguel@nuclecu.unam.mx
Cc: sparclinux@vger.rutgers.edu, sparc-list@redhat.com,
pete@RockyMountain.rahul.net, proven@MIT.EDU,
mueller@hp832.informatik.hu-berlin.de, pthreads@MIT.EDU,
Xavier.Leroy@inria.fr, kra@fsid.cvut.cz
hi Miguel:
> > Do ya know exactly how the signal semantics for threaded
> > processes is being implemented? Perhaps a pointer to the code thats
> > implementing
> > it. My purpose in checking out the Linux code is to do the same to SVR4.
>
> The behaviour depends on whether you provide CLONE_SIGHAND is set or
> not. The problem with the current implementation of the signal
> handling on Linux/SPARC together with the sigaction implementation in
> libc is that no mather how hard you clear the CLONE_SIGHAND flag,
> signals will jump to the signal handler that is stored in the libc.
> That is what is currently broken. But, as I said in the past mail as
> soon as Red Hat releases their Sparc distribution we will go ahead and
> fix that (it is a rather trivial fix).
Great, I noticed after I replied to ya that I missed your point. If we go with
this clone() approach we will have to change SVR4 that's on the Stratus system
to support these new clone semantics. Tonight I'm going to read thru the code
to get a feel for what needs to be done. Off hand I'd estimate it taking about
a week or two on the Stratus OS. What do you think? Usually my estimates are
far to optimistic.
> > Perhaps a pointer to the code thats implementing
> > it. My purpose in checking out the Linux code is to do the same to SVR4.
>
> Look into kernel/fork.c
Yea, I did, but I want to hit it again this evening.
>
> > Too bad you guys don't have time to add linuxthreads-0.3 to libc. There
> > are three assembler routine for the Intel arch that need to be done for
> > SPARC before I can use it. Looks like we need a SPARC version of:
>
> Well, after the release we will add those (next week sound good to
> you?). We can't just start adding features that have not been tested
> at this stage, we want a usable Linux/SPARC distribution as soon as
> possible.
>
> > 1. nanosleep
> > 2. sched_yield
> > 3. a Posix version of
> > A. clone
> > B. thread_start
>
> All of those take about 20 minutes of coding, don't worry, we will get
> them.
Great, that increases the odds that we will get to do what appears to be
a better implementation of pthreads.
>
> > Any idea on why I'm stuck just after NFS mounting root:
> >
> > Sending BOOTP and RARP requests.... OK
> > Root-NFS: Got RARP answer from 192.9.200.2, my address is 192.9.200.11
> > Root-NFS: Got file handle for /tftpboot/192.9.200.11 via RPC
> > VFS: Mounted root (nfs filesystem).
> > NFS server 192.9.200.2 not responding, still trying.
>
> No, I don't. Maybe on Monday we can look at this problem: just give
> us enough information to try to fix this: in what machine are you
> running this, which release of the kernel are you using, what kind of
> NFS server you have and anything else that may be relevant.
No need, I figured it out with snoop, I used SunOS tar to make the root
partition instead of the GNU tar. I was trying to boot with the console on
ttya and that also seems to be a problem. On the cg6 it's working fine. Very
fast! Looks like I need to fill in the tree a lot, YP, rlogin, etc, I'm ftp'ing
the stuff in userland and it should all be here soon. Any pointers on installing
off of the stuff that I'll need for trying out pthreads? It will be here before
I straighten out my mirror perl script stuff. Also I suspect that not all of this
is on the mirror.
? 11058034 May 25 03:17 X11R6.1.SPARC.bin.tar.gz
* 1526904 May 18 07:59 binutils-2.6.0.12.SPARC.tar.gz
11217 Aug 20 02:13 clock.c
* 99576 May 26 05:41 diffutils-2.7.SPARC.tar.gz
1695626 May 25 05:15 e2fsprogs-1.04.SPARC.prebuilt.tar.gz
770 May 25 05:17 e2fsprogs-1.04.diff.gz
DONE 1593207 Jul 18 19:04 easy.nfs.root-4.tar.gz
91561 May 28 02:53 ed-0.2.SPARC.static.tar.gz
48606 May 28 02:53 ed-0.2.SPARC.tar.gz
8661153 May 25 03:30 emacs-19.30.103.SPARC.bin.tar.gz
* 757304 May 18 08:04 gcc-2.7.2.SPARC.tar.gz
* 1841431 Jul 30 05:02 gdb-for-sparclinux-working-on-patches.gz
? 24857 May 26 01:42 gdbm-1.7.3.SPARC.tar.gz
1777219 Aug 16 08:36 linux-sparc.jdk-1.0.1-try3.shared-motif.tar.gz
3419422 Aug 16 08:45 linux-sparc.jdk-1.0.1-try3.static-motif.tar.gz
* 164173 May 26 05:55 make-3.74.SPARC.tar.gz
253550 May 17 18:18 modules-1.3.57.SPARC.static.tar.gz
* 52323 Jul 18 15:31 modules-2.0.0.SPARC.bin.tar.gz
* 105194 Jul 18 15:35 modules-2.0.0.SPARC.tar.gz
2077718 Jul 14 11:44 openwin-sparc-bin.tar.gz
4314242 Jul 14 11:53 openwin-sparc-src.tar.gz
* 933780 May 30 21:37 rpm-2.0.2-sparc.tar.gz
* 136985 May 26 03:38 sh-utils-1.12.SPARC.tar.gz
143401 May 9 00:56 tar-1.11.8.SPARC.tar.gz
181348 May 26 04:06 textutils-1.14.SPARC.tar.gz
Any thoughts on the effort on porting one of the Linux implementations
useing the clone() system call and related enhancements:
Clthreads-0.1.1 - by Pavel Krauz <kra@fsid.cvut.cz>
linuxthreads-0.3 - by Xavier Leroy (Xavier.Leroy@inria.fr)
verses using a complete user space implementation like:
pthreads-1_60_beta5 - by Chris Provenzano (MIT)
or perhaps the next release of
threads by Frank Mueller (GNU?)
I suppose the complete user space implementation is fast to 'port' but
the Linux clone() approach is more layered and leaves the kernel like
problems in the kernel where I sospect it will be easiest to fix future
problems. The code is well know and the concepts well understood. Having
the pthreads library deal with process blocking in the kernel seems like
a messy solution. Although I could likley get something working sooner,
I feel a more complete solution, including good debugger support will be
needed. I think having the threads information in the kernel will make it
easier for the debugger to provide thread support as SunSoft`s dbx Debugger
and GNU's gdb currently do. Since the concept is cleaner, the debugging tail on
the work effort is likley longer with the user space implementation. Also the
clone() approach will allow us to use both CPU's in the Polo systems.
-pete
~
