Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.

Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.

[forsyth]

>>thread==process. There is a rfork() equivalent (clone(2)) and model is
>>exactly the same as on Plan 9 (process as a set of components that can be
>>shared between several processes; fork() as a special case of more generic

no it is not equivalent.
would that it were.

Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.

[Alexander Viro]

On Fri, 1 Sep 2000 forsyth@caldo.demon.co.uk wrote:

> >>thread==process. There is a rfork() equivalent (clone(2)) and model is
> >>exactly the same as on Plan 9 (process as a set of components that can be
> >>shared between several processes; fork() as a special case of more generic
> 
> no it is not equivalent.
> would that it were.

You can have multiple stacks. If anything, work by ESP is better than by
TSS. "Current stack pointer" makes sense on most of architectures. TSS
doesn't.

Lack of stack-splitting is not an accident - stack is not a magic object.
It's just an anonymous mapping with MAP_GROWSDOWN in flags.
<checks the manpage>
<damn>
OK, so it's time for patch to mmap.2. Omitted piece being:

	MAP_GROWSDOWN	created mapping will behave like a stack - grow
			downwards upon pagefaults. Stacks are not
			special in any respects - they are nothing but
			anonymous mappings that can grow.

Sorry. That makes my original reaction somewhat over-the-top. Umhm...
OK, I'll look through the thing (drawterm, that is) and try to see what
can be done.

Anyway, TSS hack is doomed - it's not going to work on 2.4. We used to
allocate a separate TSS for each task, but that essentially forced a TLB
flush upon every context switch. And it hurts a lot. Current kernel has a
TSS per CPU and does needed updates by hands - it turned out to be faster
than jump on TSS. So something has to be done anyway. Yes, 2.4 is not
released yet, but you can be 100% sure that this change will not be
reverted.

Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.

[nigel]

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

I can confirm that it compiles under FreeBSD RELENG_4 (i.e the most
recent stable release of 4.1).


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

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.
Date: Fri, 1 Sep 2000 15:59:46 -0400
Message-ID: <200009012000.QAA26992@cse.psu.edu>

As far as drawterm is concerned, 
the latest update had patches to 
make drawterm work under FreeBSD
using the Posix thread library.

The Linux drawterm will not work
in most other places, even under 
binary emulation, because it depends
on the task segment selector as
a unique thread id.  This is the same
reason that the Inferno Linux binaries
don't work under other OSes with
Linux binary emulation.

Russ

Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.

[jmk]

Alexander Viro <viro@math.psu.edu>:
	>On Fri, 1 Sep 2000, Russ Cox wrote:
	>
	>> The Linux drawterm will not work
	>> in most other places, even under 
	>> binary emulation, because it depends
	>> on the task segment selector as
	>> a unique thread id.  This is the same
	>
	>Sorry? "other places" include 2.4, for one thing. Why using gross
	>architecture-dependent tricks, when PID is there? On Linux
	>thread==process. There is a rfork() equivalent (clone(2)) and model is
	>exactly the same as on Plan 9 (process as a set of components that can be
	>shared between several processes; fork() as a special case of more generic
	>operation that copies a subset of components and uses the old ones for the
	>rest, etc.)
	>
	>Use of TSS happened to work on x86 prior to 2.3.11 or so, but that relied
	>on the details of task_struct allocation. 2.4 has TSS-per-CPU  setup and
	>doesn't bother with changing the register at all - it's cheaper to do
	>everything by hands. Besides, it lifts the limit on number of processes
	>and allows to avoid quite a few TLB flushes.
	>
	>Use getpid() - it's at least more portable than %tss and definitely much
	>saner.
	>
	>> reason that the Inferno Linux binaries
	>> don't work under other OSes with
	>> Linux binary emulation.
	>
	>Ditto.

Phil Winterbottom and I did the original Inferno emulation port to Linux
in, I think, 1996 and that is where a lot of the drawterm code came from.
At that time few of the wonders you describe above were available. Sure, it's
a gross architecture-dependent trick but it was no worse than what we were
porting to at the time.

I'm glad there are now alternatives which could be used to rewrite the code
more portably, should anyone care to do so. Let's leave it at that.

--jim

Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.

[Russ Cox]

As far as drawterm is concerned, 
the latest update had patches to 
make drawterm work under FreeBSD
using the Posix thread library.

The Linux drawterm will not work
in most other places, even under 
binary emulation, because it depends
on the task segment selector as
a unique thread id.  This is the same
reason that the Inferno Linux binaries
don't work under other OSes with
Linux binary emulation.

Russ

Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.

[Alexander Viro]

On Fri, 1 Sep 2000, Russ Cox wrote:

> The Linux drawterm will not work
> in most other places, even under 
> binary emulation, because it depends
> on the task segment selector as
> a unique thread id.  This is the same

Sorry? "other places" include 2.4, for one thing. Why using gross
architecture-dependent tricks, when PID is there? On Linux
thread==process. There is a rfork() equivalent (clone(2)) and model is
exactly the same as on Plan 9 (process as a set of components that can be
shared between several processes; fork() as a special case of more generic
operation that copies a subset of components and uses the old ones for the
rest, etc.)

Use of TSS happened to work on x86 prior to 2.3.11 or so, but that relied
on the details of task_struct allocation. 2.4 has TSS-per-CPU  setup and
doesn't bother with changing the register at all - it's cheaper to do
everything by hands. Besides, it lifts the limit on number of processes
and allows to avoid quite a few TLB flushes.

Use getpid() - it's at least more portable than %tss and definitely much
saner.

> reason that the Inferno Linux binaries
> don't work under other OSes with
> Linux binary emulation.

Ditto.

Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.

[presotto]

Dong lin, dong@research.bell-labs.com, ported both IL and 9P to BSD.

Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.

[lucio]

> Is anybody working on connecting stuff for these 2 OS's?  Plan9

I was, while in Cape Town.  When I got back to my office in
Johannesburg, I gave Alef priority.  Now that Alef is on ice pending
some feedback, I guess I should go back to the IL/9P port.  I left
some of the ground work behind and inaccessible, but the important
details have come back with me.

> contains a patch for FreeBSD-3.2 which adds IL protocol.  I had a
> first look at the patch.  It seems to be in conflict with the IPv6,
> but mostly the patch can easily fixed, except...  I don't understand
> the stuff not enough to make it go.  But I think, IL support should be
> integrated into official FreeBSD.
> 
I think I have a good handle on it.  The Stevens books will no doubt
help a lot.  My efforts are towards a port to NetBSD (which moves more
slowly than FreeBSD, and is a little divergent) but by the time I'm
finished, I hope to produce results for all the *BSDs.  I leave it to
someone with a stronger stomach to deal with Linux.

> Neither I had success with drawterm.  It seems to depend on
> Linux-style threads not available on my system.  Is it worth (will it
> work?)  to add linuxthreads port to the system?

The POSIX threads are standard across most (all?)  modern Unixes.
They need installing (I have no doubt there's a pthread/MIT-pthread
port for FreeBSD) and didn't quite seem to suffice to get drawterm to
run under NetBSD, but I haven't dug any deeper - those are really
murky waters.

I would dearly like to share ideas with others that want to integrate
Plan 9 into other environments as I do.  There are lots of options,
and too few objectives that would make it easier to choose a
particular path.

++L

Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.

[Nigel Roles]

Not under FreeBSD 4 they don't. Standard part of glibc.

> They need installing (I have no doubt there's a pthread/MIT-pthread
> port for FreeBSD) and didn't quite seem to suffice to get drawterm to

Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.

[Nigel Roles]

Or should I say, you just compile with cc -pthreads, which is 
equivalent to linking with libc_r in place of libc.

> They need installing (I have no doubt there's a pthread/MIT-pthread
> port for FreeBSD) and didn't quite seem to suffice to get drawterm to

Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.

[William K. Josephson]

On Wed, Aug 30, 2000 at 12:13:01PM +0000, lucio@proxima.alt.za wrote:
> > Is anybody working on connecting stuff for these 2 OS's?  Plan9
> 
> I was, while in Cape Town.  When I got back to my office in
> Johannesburg, I gave Alef priority.  Now that Alef is on ice pending
> some feedback, I guess I should go back to the IL/9P port.  I left

If I recall, someone at the labs has already done a 9P port to FreeBSD.

 -WJ

Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.

[Lucio De Re]

On Wed, Aug 30, 2000 at 12:29:13PM -0400, William K. Josephson wrote:
> 
> If I recall, someone at the labs has already done a 9P port to FreeBSD.
> 
It is necessarily OS specific.  My other OS <grin> is NetBSD, and I
was trying to shoehorn the FreeBSD code into NetBSD.  Others have
mentioned that FreeBSD-4 is different enough to require additional
work.

I'm planning to study all three aspects of networking in the port to
NetBSD.

++L

[9fans] FreeBSD 4.0 / Plan9 3rd ed.

[Wilhelm B. Kloke]

Is anybody working on connecting stuff for these 2 OS's?
Plan9 contains a patch for FreeBSD-3.2 which adds IL protocol. I had a first
look at the patch. It seems to be in conflict with the IPv6,
but mostly the patch can easily fixed, except...
I don't understand the stuff not enough to make it go. But I think,
IL support should be integrated into official FreeBSD.

Neither I had success with drawterm. It seems to depend on Linux-style
threads not available on my system. Is it worth (will it work?) to add
linuxthreads port to the system?
-- 
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257

Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.

[Nigel Roles]

Don't try the linuxthreads port. I had no success at all.
For threads, it is much better to use the glibc posix threads.

There is a patch on the website to get drawterm to compile under 
FreeBSD 4 (I think). Try that. If that doesn't work remind me, and I'll 
take a look.

As for IL in the kernel, I've not looked yet, but will.

> Is anybody working on connecting stuff for these 2 OS's?
> Plan9 contains a patch for FreeBSD-3.2 which adds IL protocol. I had a first
> look at the patch. It seems to be in conflict with the IPv6,
> but mostly the patch can easily fixed, except...
> I don't understand the stuff not enough to make it go. But I think,
> IL support should be integrated into official FreeBSD.
> 
> Neither I had success with drawterm. It seems to depend on Linux-style
> threads not available on my system. Is it worth (will it work?) to add
> linuxthreads port to the system?
> -- 
> Dipl.-Math. Wilhelm Bernhard Kloke
> Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
> Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257

Re: [9fans] FreeBSD 4.0 / Plan9 3rd ed.

[William K. Josephson]

On Wed, Aug 30, 2000 at 09:12:04AM +0000, Wilhelm B. Kloke wrote:

> Neither I had success with drawterm. It seems to depend on Linux-style
> threads not available on my system. Is it worth (will it work?) to add
> linuxthreads port to the system?

There is a port of LinuxThreads to FreeBSD in the FreeBSD ports.  I
had also ported most of the drawterm threads to using FreeBSD rfork(2)
at one point.  The only minor difficulty there in 3.2 was that the man
page for rfork incorrectly claimed that the stack was split given the
appropriate flags.  I haven't any idea if the man page reflects
reality now.