Re: [9fans] Why rio instead of 8 1/2

Re: [9fans] Why rio instead of 8 1/2

[okamoto]

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

Thank you very much Rob.

It's not easy to understand Rio to me, because this is my first 
experience to see her functions and implementation.  Please
forgive me if I'm too noisy on this topic.

When I do "ps", I find 7 rio processes for one window.  I now
think I got it right(???).  Those are, in the order from early to late,
1) main process, 
2) mouseproc made from initmouse(), 
3) kbdproc from initkeyboard(), 
4) timeproc from timeinit(), 
5) wctlproc from filsysinit() in fsys.c, 
6) filsysproc also from the same function as (5), 
7) /bin/rc or approapriate file to be called
        called from initcmd() or new().

Then, No. (2) and (5) procs are marked as rendez.  I looked into
sources, however, I failed to understand where the No.2 and 5
processes are called rendezvous.  I know I'm missing something...

Kenji


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

From: "rob pike" <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: [9fans] Why rio instead of 8 1/2
Date: Sat, 8 Jul 2000 15:15:10 -0400
Message-ID: <200007081915.PAA03839@cse.psu.edu>

> Please make me clear what is the reason why the new release adopted new 
> graphic model.

Many reasons.  Most important is that the bitblt model is twenty years
old now and woefully inadequate for representing the kinds of things
people do in modern interfaces on modern machines.  The old stuff
didn't even have the *idea* of color, let alone a way to use it.  And
for multibit colored pixels, operations like AND and OR are usually
nonsense.  XOR still has merit, but losing XOR was a small price to
pay for the greater generality of alpha-blended image composition.

Another reason is that we needed to move to true color, which is not a
power of two bits per pixel, and is multichannel, which further
reduces the suitability of bitblt.

Another reason is that compiling on the fly, although a great idea in
1981 and perhaps in the future, is problematic for a portable system.
If all we had was x86s we might be able to make it work, but with
MIPS, SPARC, ARM, PowerPC, Alpha - and the list continues to grow -
the difficulty of maintaining multiple on-the-fly compilers pales
beside the problem of keeping caches synchronized when the
architectures often leave caching details up to the motherboard
builder.  The last release of Plan 9 represented the limits of our
ability to cope.  On-the-fly compilation for bitblt had to go.

Another reason is that we wanted to use VGA accelerator hardware.

Finally, it was time for a change in the way the system worked.  It
just looked old.

So we redid it all. That's the way we work.

The X people are wrestling with many of these issues today.

-rob

Re: [9fans] Why rio instead of 8 1/2

[rob pike]

> Why acme lets the /dev/consctl unwrite(read)able?
If you were turn turn echo off in acme `win' sessions, it would be impossible
to type input to programs, since win reads its input by extracting the visible
characters from the frame.

-rob

Re: [9fans] Why rio instead of 8 1/2

[okamoto]

Thanks Rob, again.

>3) This topic is discussed in the Acme paper.  

Oh, sorry.
I have to learn more on rio's codes which is very interesting to me.

I think or hope I got the main stream of the rio by your help,  and tried to
update the ktrans for this release.  Yes, I can input Jpanese partially now.☺
I'm still in the stage of evaluating what is most economic and elegant...
Ritchie-san's previous notes on this topic is very impressive, and I've 
read it many times so far.  Yes, he did a great job at the previous release.  
Why he did not do it again.  I'm now trying to do something different from it, 
however, it seems very hard...

One questions arose from this process.
Why acme lets the /dev/consctl unwrite(read)able?

Kenji

Re: [9fans] Why rio instead of 8 1/2

[rob pike]

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

1) The processes are running in the same, shared memory
created by rfork(RFMEM).
2) The wctl named pipe makes it easy for programs like /bin/window
to find the window system even if they are not in its name space.
this is an issue for plumber commands.
3) This topic is discussed in the Acme paper.  There is a data type
called XFid that is used to manage a pool of threads in the main
proc to handle requests on behalf of clients of the file system
process.  The advantage of this design is that anything that needs
to access global data can do much less interlocking if it's a thread
in the main proc rather than a separate proc.  Threads are coroutines
that schedule cleanly; procs are true process scheduled at arbitrary
points by the operating system.

-rob


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

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

Thanks Rob!

Now, I got that it shows the state of channel communication.


I got another difficulty to understand how the rio works.
Of course it comes from my personal inablility to read the sources,
however, I suppose it's not so easy to some of Plan 9 users like me, either.

1) all the seven procs have the same memory size, and grows
     coincidently alltogether.  Why?  Only the process of threadmain()
     can grow, can't it?

2) proc wctlproc does only check "New" command, and writectl()
     is called from xfidwrite() which is checked by normal filsyproc().
     So, why /srv/riowctl.$user.$pid is posted?  The "New" command
     can also be checked from the normal filsysproc(), can't it?

3) filsysproc() calls file operation functions in fsys.c, and many of
     those functions call  coresponding xfidxxx functions through
     channel x->c.  Why these two processes are separated?  Or
     what is the merrit to use channel for this purpose, but not just
     function call by pointer alone?

Kenji


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

From: "rob pike" <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Why rio instead of 8 1/2
Date: Thu, 13 Jul 2000 19:34:52 -0400
Message-ID: <200007132334.TAA14780@cse.psu.edu>

	Then, No. (2) and (5) procs are marked as rendez.  I looked into
	sources, however, I failed to understand where the No.2 and 5
	processes are called rendezvous.  I know I'm missing something...

They aren't called rendezvous, they're in the rendezvous state.
That field of the ps output is the state of the process, typically a system
call name (such as Wait, Read, etc.) or a process state (Fault, Rendez,
etc.)

-rob

Re: [9fans] Why rio instead of 8 1/2

[okamoto]

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

Thanks Rob!

Now, I got that it shows the state of channel communication.


I got another difficulty to understand how the rio works.
Of course it comes from my personal inablility to read the sources,
however, I suppose it's not so easy to some of Plan 9 users like me, either.

1) all the seven procs have the same memory size, and grows
     coincidently alltogether.  Why?  Only the process of threadmain()
     can grow, can't it?

2) proc wctlproc does only check "New" command, and writectl()
     is called from xfidwrite() which is checked by normal filsyproc().
     So, why /srv/riowctl.$user.$pid is posted?  The "New" command
     can also be checked from the normal filsysproc(), can't it?

3) filsysproc() calls file operation functions in fsys.c, and many of
     those functions call  coresponding xfidxxx functions through
     channel x->c.  Why these two processes are separated?  Or
     what is the merrit to use channel for this purpose, but not just
     function call by pointer alone?

Kenji


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

From: "rob pike" <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Why rio instead of 8 1/2
Date: Thu, 13 Jul 2000 19:34:52 -0400
Message-ID: <200007132334.TAA14780@cse.psu.edu>

	Then, No. (2) and (5) procs are marked as rendez.  I looked into
	sources, however, I failed to understand where the No.2 and 5
	processes are called rendezvous.  I know I'm missing something...

They aren't called rendezvous, they're in the rendezvous state.
That field of the ps output is the state of the process, typically a system
call name (such as Wait, Read, etc.) or a process state (Fault, Rendez,
etc.)

-rob

Re: [9fans] Why rio instead of 8 1/2

[rob pike]

	Then, No. (2) and (5) procs are marked as rendez.  I looked into
	sources, however, I failed to understand where the No.2 and 5
	processes are called rendezvous.  I know I'm missing something...

They aren't called rendezvous, they're in the rendezvous state.
That field of the ps output is the state of the process, typically a system
call name (such as Wait, Read, etc.) or a process state (Fault, Rendez,
etc.)

-rob

[9fans] Why rio instead of 8 1/2

[rob pike]

> Please make me clear what is the reason why the new release adopted new 
> graphic model.

Many reasons.  Most important is that the bitblt model is twenty years
old now and woefully inadequate for representing the kinds of things
people do in modern interfaces on modern machines.  The old stuff
didn't even have the *idea* of color, let alone a way to use it.  And
for multibit colored pixels, operations like AND and OR are usually
nonsense.  XOR still has merit, but losing XOR was a small price to
pay for the greater generality of alpha-blended image composition.

Another reason is that we needed to move to true color, which is not a
power of two bits per pixel, and is multichannel, which further
reduces the suitability of bitblt.

Another reason is that compiling on the fly, although a great idea in
1981 and perhaps in the future, is problematic for a portable system.
If all we had was x86s we might be able to make it work, but with
MIPS, SPARC, ARM, PowerPC, Alpha - and the list continues to grow -
the difficulty of maintaining multiple on-the-fly compilers pales
beside the problem of keeping caches synchronized when the
architectures often leave caching details up to the motherboard
builder.  The last release of Plan 9 represented the limits of our
ability to cope.  On-the-fly compilation for bitblt had to go.

Another reason is that we wanted to use VGA accelerator hardware.

Finally, it was time for a change in the way the system worked.  It
just looked old.

So we redid it all. That's the way we work.

The X people are wrestling with many of these issues today.

-rob