Date: Fri, 18 Apr 1997 22:35:48 +0800 From: Peter Wemm <peter@spinner.dialix.com> To: Gunther Hipper <gunther@informatik.uni-rostock.de> Cc: smp@FreeBSD.org Subject: Re: Since last sup on April 18th an error in make depend Message-ID: <199704181435.WAA28387@spinner.DIALix.COM> In-Reply-To: Your message of "Fri, 18 Apr 1997 12:49:45 %2B0200." <199704181049.MAA04095@donau.informatik.uni-rostock.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Gunther Hipper wrote:
[..]
> So, i supped the today in the morning the latest SMP-sys-tree with a:
> src-sys release=smp host=cvsup.freebsd.org hostbase=/home base=/usr prefix=/u
sr/sup/cvssmp delete
> old use-rel-suffix
[..]
> In file included from ../../i386/i386/genassym.c:71:
> ../../nfs/nfsdiskless.h:68: field `swap_args' has incomplete type
> ../../nfs/nfsdiskless.h:75: field `root_args' has incomplete type
> ../../nfs/nfsdiskless.h:87: field `swap_args' has incomplete type
> ../../nfs/nfsdiskless.h:93: field `root_args' has incomplete type
> ../../i386/i386/genassym.c: In function `main':
> ../../i386/i386/genassym.c:119: `UMAXPTDI' undeclared (first use this functio
n)
> ../../i386/i386/genassym.c:119: (Each undeclared identifier is reported only
once
> ../../i386/i386/genassym.c:119: for each function it appears in.)
> ../../i386/i386/genassym.c:119: `UMAXPTEOFF' undeclared (first use this funct
ion)
> *** Error code 1
"OOPS!!" Oh dear! It looks like I accidently imported the latest
-current into the real tree rather than my copy of it!!
UH OH!! Looks like I'd better get on with it and fix it again. :-]
The problem you saw was because you have got an mixed up version of the
kernel. Some parts are abut 2 months older than others due to the
brain-dead design of cvs. I have just committed my merged version so far,
but I do not think it'll work yet. There are problems to be resolved with
the common_tss code in -current (that I committed to -current, based on
somebody else's code.)
The changes here are 80% of the way towards being able to have pthreads
running via the threading package in libc_r actually executing in parallel
on seperate cpu's.... What's remaining is locking on the page tables/
pmaps when a single instance of a process address space is running on two
cpu's, and a "driver" engine for libc_r's threads package. (basically,
remove the select() based scheduler and use rfork threads instead)
Cheers,
-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704181435.WAA28387>