[9fans] plan9port update

[9fans] plan9port update

[Russ Cox]

There is a big update to Plan 9 port available now, at
http://swtch.com/plan9port.

The most significant user-visible change is that the entire system is
documented.  Intro(1) is a good starting point.

The most significant code change is that the thread library now uses
pthreads and ucontext(3) when possible.  This means that programs should
work properly on Linux 2.6 now, and that real threading can be used on
SunOS and Mac OS X now.  It also means porting the system is easier --
there's no sparc assembly at all in the tree, for example.  Finally, it means
that various hangs people saw when using the acme Edit command
are finally gone.

There are many many small improvements since the last real release,
far too many to list individually.   Intro(1) gives a list of man pages that
describe interesting differences from Plan 9 proper.  

Thanks to everyone who helped test for the last week or two.
I've built and run the system on Mac OS X 10.3, Linux 2.4, 2.6, FreeBSD 5,
and SunOS 5.9 today, but there may well be small things that need to be
fixed still for other platforms.  If you're feeling a bit conservative you
might wait a week or two to let others find those.

Enjoy.
Russ

Re: [9fans] plan9port update

[David Leimbach]

Excellent.  I'll be working from CVS for my attempt to SDL-ify
libdraw... I see a bunch of files have been touched.

Dave


On Fri, 14 Jan 2005 16:23:18 -0500, Russ Cox <russcox@gmail.com> wrote:
> There is a big update to Plan 9 port available now, at
> http://swtch.com/plan9port.
> 
> The most significant user-visible change is that the entire system is
> documented.  Intro(1) is a good starting point.
> 
> The most significant code change is that the thread library now uses
> pthreads and ucontext(3) when possible.  This means that programs should
> work properly on Linux 2.6 now, and that real threading can be used on
> SunOS and Mac OS X now.  It also means porting the system is easier --
> there's no sparc assembly at all in the tree, for example.  Finally, it means
> that various hangs people saw when using the acme Edit command
> are finally gone.
> 
> There are many many small improvements since the last real release,
> far too many to list individually.   Intro(1) gives a list of man pages that
> describe interesting differences from Plan 9 proper.
> 
> Thanks to everyone who helped test for the last week or two.
> I've built and run the system on Mac OS X 10.3, Linux 2.4, 2.6, FreeBSD 5,
> and SunOS 5.9 today, but there may well be small things that need to be
> fixed still for other platforms.  If you're feeling a bit conservative you
> might wait a week or two to let others find those.
> 
> Enjoy.
> Russ
>

Re: [9fans] plan9port update

[Matthias Teege]

On Fri, 14 Jan 2005 16:23:18 -0500, Russ Cox <russcox@gmail.com> wrote:
> There is a big update to Plan 9 port available now, at
> http://swtch.com/plan9port.

I compile it under Linux 2.6.8. It works but I can't use rio anymore
because I can't create new "windows". I can select "New" from the menu
but don't get the "cross". An older version of plan9ports, I think it
is from july 2004, works.

Matthias

Re: [9fans] plan9port update

[Russ Cox]

> I compile it under Linux 2.6.8. It works but I can't use rio anymore
> because I can't create new "windows". I can select "New" from the menu
> but don't get the "cross". An older version of plan9ports, I think it
> is from july 2004, works.

What if you go to a different terminal and run DISPLAY=:0 xterm & ?
And then 9term instead of xterm?

I'm running on Linux 2.6.8-1 Debian with no problems.

Russ

Re: [9fans] plan9port update

[andrey mirtchovski]

> I compile it under Linux 2.6.8. It works but I can't use rio anymore
> because I can't create new "windows". I can select "New" from the menu
> but don't get the "cross". An older version of plan9ports, I think it
> is from july 2004, works.
> 
> Matthias

it's probably complaining in the terminal window (the one where X logs
its error messages) that it can't find 9term or 9term won't start.

Re: [9fans] plan9port update

[boyd, rounin]

> it's probably complaining in the terminal window (the one where X logs
> its error messages) that it can't find 9term or 9term won't start.

xconsole

Re: [9fans] plan9port update

[Russ Cox]

> I compile it under Linux 2.6.8. It works but I can't use rio anymore
> because I can't create new "windows". I can select "New" from the menu
> but don't get the "cross". An older version of plan9ports, I think it
> is from july 2004, works.

Gentoo uses 2.6.8 kernels but without NPTL (Linux's new posix
threading library) turned on by default.  Plan9port was assuming
that the kernel version alone was enough to tell whether NPTL
was in use, but it's not.  

The latest version detects NPTL during the build and behaves
accordingly.  (If you do want NPTL on your Gentoo system, you
can list it in your USE line in /etc/make.conf and then rebuild
glibc.  See the Gentoo documentation for more.)

The NPTL (aka TLS, since along with NPTL comes better support for
thread-local storage) issue is certainly what's causing Opera to
get tripped up too. 

Libthread also tries to do better than seg fault in the case
where you're running binaries for NPTL on non-NPTL systems:

tux=; ./o.tprimes
./o.tprimes: cannot use LinuxThreads as pthread library; see
/usr/local/plan9/src/libthread/README.Linux
tux=; 

Russ

Re: [9fans] plan9port update

[Noah Evans]

You're a scholar and a gentlemen as always russ.


On Tue, 18 Jan 2005 13:49:30 -0500, Russ Cox <russcox@gmail.com> wrote:
> > I compile it under Linux 2.6.8. It works but I can't use rio anymore
> > because I can't create new "windows". I can select "New" from the menu
> > but don't get the "cross". An older version of plan9ports, I think it
> > is from july 2004, works.
> 
> Gentoo uses 2.6.8 kernels but without NPTL (Linux's new posix
> threading library) turned on by default.  Plan9port was assuming
> that the kernel version alone was enough to tell whether NPTL
> was in use, but it's not.
> 
> The latest version detects NPTL during the build and behaves
> accordingly.  (If you do want NPTL on your Gentoo system, you
> can list it in your USE line in /etc/make.conf and then rebuild
> glibc.  See the Gentoo documentation for more.)
> 
> The NPTL (aka TLS, since along with NPTL comes better support for
> thread-local storage) issue is certainly what's causing Opera to
> get tripped up too.
> 
> Libthread also tries to do better than seg fault in the case
> where you're running binaries for NPTL on non-NPTL systems:
> 
> tux=; ./o.tprimes
> ./o.tprimes: cannot use LinuxThreads as pthread library; see
> /usr/local/plan9/src/libthread/README.Linux
> tux=;
> 
> Russ
>

Re: [9fans] plan9port update

[kvchokw02]

On Tue, 18 Jan 2005 00:16:04 +0000, Russ Cox wrote:

> There is a big update to Plan 9 port available now, at
> http://swtch.com/plan9port.

Great stuff, but 2 comments.

1) The link to the web interface to the cvs repository
(http://cvs.pdos.lcs.mit.edu/cvs/plan9/) seems to have disappeared from
the web-site and from the docs in the download (I had to search through my
browser history to find it).

2) There may be some problem building the web manual if the installation
isn't in /usr/local/plan9.  Everything seems to work fine, but I got the
following messages near end of install.log:

Building web manual...
rc ./manweb
ls: [a-z0-9:]*.[0-9]*: No such file or directory
dhtml: unknown directive .(0x2e) at <stdin>:#13283
sed: Can't open /usr/local/plan9/dist/checkman.awk
Done.

When I installed in /usr/local/plan9, I got the following instead:

Building web manual...
rc ./manweb
ls: [a-z0-9:]*.[0-9]*: No such file or directory
dhtml: unknown directive .(0x2e) at <stdin>:#13283
Done.

I don't know if the set error indicates something serious or not.

	- Peter Canning

Re: [9fans] plan9port update

[Russ Cox]

> Great stuff, but 2 comments.

Good catches both of them.  I've updated cvs.1
to add a link to the web interface, I've changed
the manweb script to silence those errors, which are
harmless, and I've changed fixurls to remove the
hard-coded reference to /usr/local/plan9.

I also fixed a few problems wherein libthread would not
build on newer Linux systems.  

Sorry for the delay -- had to go in and reboot my CVS
server to get it to talk to me.  Consolefs is something
I dearly miss.

Russ

Re: [9fans] plan9port update

[Ronald G. Minnich]

On Tue, 18 Jan 2005, Russ Cox wrote:

> Sorry for the delay -- had to go in and reboot my CVS
> server to get it to talk to me.  Consolefs is something
> I dearly miss.

you need one of those nice Ethernet-based power switches. Quite fun. 

ron

Re: [9fans] plan9port update

[kvchokw02]

Awesome.  This new stuff seems to have fixed a problem with Getdir
(hanging) that I hadn't had time to track down and report yet.

	thanks,
	Peter Canning

 On Wed, 19 Jan 2005
04:35:55 +0000, Russ Cox wrote:

>> Great stuff, but 2 comments.
> 
> Good catches both of them.  I've updated cvs.1
> to add a link to the web interface, I've changed
> the manweb script to silence those errors, which are
> harmless, and I've changed fixurls to remove the
> hard-coded reference to /usr/local/plan9.
> 
> I also fixed a few problems wherein libthread would not
> build on newer Linux systems.  
> 
> Sorry for the delay -- had to go in and reboot my CVS
> server to get it to talk to me.  Consolefs is something
> I dearly miss.
> 
> Russ

Re: [9fans] plan9port update

[YAMANASHI Takeshi]

I don't know what I'm writing exactly but...

> There is a big update to Plan 9 port available now, at
> http://swtch.com/plan9port.
 :
> It also means porting the system is easier --
> there's no sparc assembly at all in the tree, for example.

Does this means I can compile and run p9port on Tru64 UNIX?
When I tried last, there was no lock related assembly codes there.
-- 

Re: [9fans] plan9port update

[Russ Cox]

> Does this means I can compile and run p9port on Tru64 UNIX?
> When I tried last, there was no lock related assembly codes there.

Drawterm once ran on Tru64 atop pthreads with no problems,
so it's worth trying.  You may have to create a getcallerpc-alpha.c
in src/lib9:

    #include <u.h>
    #include <libc.h>
    ulong getcallerpc(ulong *x) { return 0; }

is fine to get going.  

Russ

RE: [9fans] plan9port update

[Benjamin Huntsman]

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

Minus the Sparc assembly, will it still run on Sparc?  
 
As for Tru64, to my knowledge, no one has done any Alpha related work in some time...  I'd be interested to see if plan9port runs on Tru64, too...  Unfortunately, my Tru64-system-to-be isn't quite functional.... yet.
 
-Ben
 

	-----Original Message----- 
	From: YAMANASHI Takeshi [mailto:9.nashi@gmail.com] 
	Sent: Sun 1/16/2005 9:10 PM 
	To: 9fans@cse.psu.edu 
	Cc: 
	Subject: Re: [9fans] plan9port update
	
	

	I don't know what I'm writing exactly but...
	
	> There is a big update to Plan 9 port available now, at
	> http://swtch.com/plan9port.
	 :
	> It also means porting the system is easier --
	> there's no sparc assembly at all in the tree, for example.
	
	Does this means I can compile and run p9port on Tru64 UNIX?
	When I tried last, there was no lock related assembly codes there.
	--
	
	
	


[-- Attachment #2.1: Type: text/plain, Size: 292 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/ms-tnef;
	name="winmail.dat"
	Content-Transfer-Encoding: base64

[-- Attachment #2.2: winmail.dat.suspect --]
[-- Type: application/octet-stream, Size: 4182 bytes --]

Re: [9fans] plan9port update

[William K. Josephson]

On Sun, Jan 16, 2005 at 10:23:51PM -0800, Benjamin Huntsman wrote:
> Minus the Sparc assembly, will it still run on Sparc?  

It should; I believe Russ has been testing on Athena.

> As for Tru64, to my knowledge, no one has done any Alpha related work
> in some time...  I'd be interested to see if plan9port runs on Tru64,
> too...  Unfortunately, my Tru64-system-to-be isn't quite
> functional....  yet.

The reason there was support for the Alpha was that
Harvard was a die-hard DEC shop (not so much anymore).
The computer society, EECS, and the main arts and sciences
cluster all ran Alpha.  Neither of us is at Harvard any
more and in so far as Princeton is not x86 it is a Sun
shop.