From mboxrd@z Thu Jan 1 00:00:00 1970 From: okamoto@granite.cias.osakafu-u.ac.jp Message-Id: <200007131119.HAA24058@cse.psu.edu> To: plan9@granite.cias.osakafu-u.ac.jp Subject: Re: [9fans] Why rio instead of 8 1/2 Date: Thu, 13 Jul 2000 20:20:00 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-tazjeaduxezpglgtlawnethgjx" Topicbox-Message-UUID: da8b6c8e-eac8-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-tazjeaduxezpglgtlawnethgjx Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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 --upas-tazjeaduxezpglgtlawnethgjx Content-Type: message/rfc822 Content-Disposition: inline Received: from elmo.cias.osakafu-u.ac.jp (elmo.cias.osakafu-u.ac.jp [157.16.103.2]) by granite.cias.osakafu-u.ac.jp (8.9.3/8.9.3) with ESMTP id EAA14643 for ; Sun, 9 Jul 2000 04:19:30 +0900 Received: from cse.psu.edu (majordom@claven.cse.psu.edu [130.203.3.50]) by elmo.cias.osakafu-u.ac.jp (8.9.3/3.7W-00051217) with ESMTP id EAA13091; Sun, 9 Jul 2000 04:19:38 +0900 (JST) Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) with SMTP id PAA03906; Sat, 8 Jul 2000 15:16:44 -0400 (EDT) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Sat, 8 Jul 2000 15:15:23 -0400 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id PAA03843 for 9fans-outgoing; Sat, 8 Jul 2000 15:15:19 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.cs.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id PAA03839 for <9fans@cse.psu.edu>; Sat, 8 Jul 2000 15:15:14 -0400 (EDT) Message-Id: <200007081915.PAA03839@cse.psu.edu> Subject: [9fans] Why rio instead of 8 1/2 From: "rob pike" Date: Sat, 8 Jul 2000 15:15:10 -0400 To: 9fans@cse.psu.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk > 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 --upas-tazjeaduxezpglgtlawnethgjx--