From owner-9fans@cse.psu.edu Tue Aug 1 00:20:10 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id AAA07921 for 9fans-outgoing; Tue, 1 Aug 2000 00:20:10 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from cackle.proxima.alt.za (cackle.proxima.alt.za [196.30.44.141]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id AAA07907 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 00:19:58 -0400 (EDT) Received: (from lucio@localhost) by cackle.proxima.alt.za (8.9.3/8.9.1) id GAA04370; Tue, 1 Aug 2000 06:18:44 +0200 (SAST) Date: Tue, 1 Aug 2000 06:18:43 +0200 From: Lucio De Re To: presotto@plan9.bell-labs.com Cc: 9fans@cse.psu.edu Subject: Re: [9fans] The IPv6 in Plan9 Message-ID: <20000801061843.E2173@cackle.proxima.alt.za> Reply-To: lucio@proxima.alt.za Mail-Followup-To: presotto@plan9.bell-labs.com, 9fans@cse.psu.edu References: <200007311515.LAA18195@cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <200007311515.LAA18195@cse.psu.edu>; from presotto@plan9.bell-labs.com on Mon, Jul 31, 2000 at 11:14:54AM -0400 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu On Mon, Jul 31, 2000 at 11:14:54AM -0400, presotto@plan9.bell-labs.com wrote: > > I started an ipv6 stack and got disgusted. I decided I'ld wait until there > was someone worth talking to using it to finish. I'll probably get back to it > soon unless someone beats me to the draw. > I was going to get all political about this, but I thought better of it :-) In the extremely unlikely event that you have not heard about it, the KAME project seems very close to completion of a second IP stack for the *BSD OSes. If you need e-mail details, drop me a line or have a look at the e-mail archives for tech-net@netbsd.org, which you ought to be able to find on . Note that WinNT (or is it only Win2k?) has a putative IPv6 stack in it. The fact that it is not widely deployed can be interpreted any way one likes :-) ++L From owner-9fans@cse.psu.edu Tue Aug 1 00:25:38 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id AAA08118 for 9fans-outgoing; Tue, 1 Aug 2000 00:25:38 -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 AAA08113 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 00:25:33 -0400 (EDT) From: dhog@plan9.bell-labs.com Message-Id: <200008010425.AAA08113@cse.psu.edu> Date: Tue, 1 Aug 2000 00:25:20 -0400 To: 9fans@cse.psu.edu Subject: Re: [9fans] warning MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > I think the main reason ^p exists is > so you can reboot cpu servers from > terminals easily. It's possible to send > ^t ^t (go into another window, type > something, come back) r to reboot > a cpu server over a serial connection, > but it's too easy to forget that dance. I have a script called "tt" that I use. From con, I escape out with control-\ and type !tt r (or !tt p etc). The script is: #!/bin/rc echo XX$1 | tr X '\024' I guess it could be just a simple echo, but I don't like having control characters in shell scripts (especially "dangerous" ones). From owner-9fans@cse.psu.edu Tue Aug 1 01:42:24 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id BAA09044 for 9fans-outgoing; Tue, 1 Aug 2000 01:42:24 -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 BAA09040 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 01:42:20 -0400 (EDT) Message-Id: <200008010542.BAA09040@cse.psu.edu> Received: from ovid.cs.bell-labs.com ([135.104.50.34]) by plan9; Tue Aug 1 01:42:19 EDT 2000 To: 9fans@cse.psu.edu Subject: Re: [9fans] Installing the updates From: "Russ Cox" Date: Tue, 1 Aug 2000 01:42:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu A user could have the distribution source on a CDROM and view it via a cache file server. This would store only the files that have changed - using copy on write. I suspose this could be extended to storing only the blocks that have changed, or even file diff(1) output, or wrap(8) file even... I'am not sure if this is interesting or hedious :-) I think it's interesting, at least until you start talking about saving individual blocks or diff output, at which point it gets complicated enough to perhaps qualify as hideous. Especially given that binaries don't change much. From owner-9fans@cse.psu.edu Tue Aug 1 02:04:57 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id CAA09429 for 9fans-outgoing; Tue, 1 Aug 2000 02:04:57 -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 CAA09425 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 02:04:53 -0400 (EDT) Message-Id: <200008010604.CAA09425@cse.psu.edu> Received: from ovid.cs.bell-labs.com ([135.104.50.34]) by plan9; Tue Aug 1 02:04:52 EDT 2000 To: 9fans@cse.psu.edu Subject: Re: [9fans] Installing the updates From: "Russ Cox" Date: Tue, 1 Aug 2000 02:04:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu [didn't mean to send that first one -- misclicked] A user could have the distribution source on a CDROM and view it via a cache file server. This would store only the files that have changed - using copy on write. I suspose this could be extended to storing only the blocks that have changed, or even file diff(1) output, or wrap(8) file even... I'am not sure if this is interesting or hedious :-) I think it's interesting, at least until you start talking about saving individual blocks or diff output, at which point it gets complicated enough to perhaps qualify as hideous. Especially since with the exception of log files and the fortune database, files tend to be rewritten completely when they change. I've thought about writing such a thing a number of times, but been scared away both by not having a name for it and by the complexity of the state machine you'd need to use only a constant number of processes. I've since come up with a name -- stitch -- and I think that you can use libthread to great advantage to manage the complexity, but I haven't tried it. If you had such a thing, you could try out new wrap updates by doing gunzip < /tmp/new.9gz >/tmp/new.9 archfs /tmp/new.9 stitch -b /tmp/new.9 / which would be neat. Russ From owner-9fans@cse.psu.edu Tue Aug 1 05:16:17 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA11320 for 9fans-outgoing; Tue, 1 Aug 2000 05:16:16 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id FAA11308 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 05:16:08 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13JXtm-0003lv-00 for 9fans@cse.psu.edu; Tue, 01 Aug 2000 09:59:42 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Tue, 1 Aug 2000 08:53:27 GMT From: "Douglas A. Gwyn" Message-ID: <3985E318.10B7E8F8@arl.army.mil> Organization: U.S. Army Research Laboratory Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200007311515.LAA18248@cse.psu.edu> Subject: Re: [9fans] Installing the updates Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu rob pike wrote: > Seriously, we deliberately refused to buy into that multiple > inclusion dance, which is a hideous non-solution for the problem > of undefined dependency order on #includes. Why not use the > occasion to clean up the code so you only include once? One doesn't always have that option; for example, a header file might be part of somebody else's project on a machine far, far away. /* imported.h */ #include /* need FILE decl */ extern imp_read( FILE*, char *whatever ); Many developers take the approach that each interface header should be self-contained, so that the user of the header doesn't need to know anything about the details of the implementation of that header. Information hiding, you know. Since the C standard definitely requires idempotency for the standard headers (except ), at least the APE headers ought to conform, to ease the burden of importing non-native code. From owner-9fans@cse.psu.edu Tue Aug 1 05:16:23 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA11334 for 9fans-outgoing; Tue, 1 Aug 2000 05:16:22 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id FAA11314 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 05:16:11 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13JXtn-0003m2-00 for 9fans@cse.psu.edu; Tue, 01 Aug 2000 09:59:43 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Tue, 1 Aug 2000 08:53:50 GMT From: dawno5@uswest.net Message-ID: <9zth5.822$V54.204500@news.uswest.net> Organization: University of Bath Computing Services, UK Reply-To: o_sypher@pctechnician.net Subject: [9fans] P9 and 68k Macs?? Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu What are the odds of running Plan-9 on an old 68k mac? Has anyone tried, and if so has anyone suceeded? ________________________________________________ | In this age of digital Darwinism, some of us are ones; | | you're a zero. | |_______________________________________________| From owner-9fans@cse.psu.edu Tue Aug 1 05:45:17 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA11896 for 9fans-outgoing; Tue, 1 Aug 2000 05:45:17 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from indosuez.com ([195.115.40.229]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id FAA11892 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 05:45:12 -0400 (EDT) From: boyd.roberts@ca-indosuez.com Received: from SNPAR12. (mailer@fw-local [192.168.192.6]) by indosuez.com (8.9.3/8.9.3) with SMTP id LAA17440 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 11:42:50 +0200 (MET DST) Received: by SNPAR12.(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 4125692E.003B778B ; Tue, 1 Aug 2000 11:49:32 +0100 X-Lotus-FromDomain: BANQUE INDOSUEZ To: 9fans@cse.psu.edu Message-ID: <4125692E.003B75BD.00@SNPAR12.> Date: Tue, 1 Aug 2000 11:46:16 +0200 Subject: =?iso-8859-1?Q?R=E9f._:_Re:_[9fans]_Installing_the_updates?= Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu "Douglas A. Gwyn" wrote: Since the C standard definitely requires idempotency for the standard headers (except ), at least the APE headers ought to conform, to ease the burden of importing non-native code. The ANSI brigade strike again; idempotence of headers. Shouldn't 'to ease the burden of importing non-native code' be re-written as 'to ease the burden of importing badly written code'? -- Boyd Roberts boyd.roberts@ca-indosuez.com See, an ordinary person spends his life avoiding tense situations. A repo man spends his life getting into tense situations. -- Bud, Repo Man From owner-9fans@cse.psu.edu Tue Aug 1 06:17:42 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id GAA12395 for 9fans-outgoing; Tue, 1 Aug 2000 06:17:42 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from indosuez.com ([195.115.40.229]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id GAA12391 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 06:17:35 -0400 (EDT) From: boyd.roberts@ca-indosuez.com Received: from SNPAR12. (mailer@fw-local [192.168.192.6]) by indosuez.com (8.9.3/8.9.3) with SMTP id MAA18236 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 12:15:14 +0200 (MET DST) Received: by SNPAR12.(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 4125692E.003E6F93 ; Tue, 1 Aug 2000 12:21:57 +0100 X-Lotus-FromDomain: BANQUE INDOSUEZ To: 9fans@cse.psu.edu Message-ID: <4125692E.003E6E62.00@SNPAR12.> Date: Tue, 1 Aug 2000 12:18:43 +0200 Subject: =?iso-8859-1?Q?R=E9f._:_Re:_R=C3=A9f.=5F:=5F[9fans]=5Fproblems?= Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=GVeQIiQ4Fzl71OMReUMJeiOlSxzzZJPUv7B3itGOovhuCyHE2fV3tABc" Content-Disposition: inline Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu --0__=GVeQIiQ4Fzl71OMReUMJeiOlSxzzZJPUv7B3itGOovhuCyHE2fV3tABc Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable i made a deliberate decision when i wrote ftpnfs (ie. ftpfs glued onto NFS. it was not pretty, but it did work. re-writing the kernel XDR wa= s ghastly) to use the minimal number of ftp commands possible, in this way it would interoperate with more systems without code changes. with each new system the code has to be changed if you use SYST. i didn't use SYST. to determine if something was a directory i'd cd into it and if that succeeded it was a directory. if it didn't it was a file or directory = you couldn't access (these i presented as files), so you didn't really care= From owner-9fans@cse.psu.edu Tue Aug 1 06:22:17 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id GAA12573 for 9fans-outgoing; Tue, 1 Aug 2000 06:22:16 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from indosuez.com ([195.115.40.229]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id GAA12569 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 06:22:11 -0400 (EDT) From: boyd.roberts@ca-indosuez.com Received: from SNPAR12. (mailer@fw-local [192.168.192.6]) by indosuez.com (8.9.3/8.9.3) with SMTP id MAA18336 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 12:19:50 +0200 (MET DST) Received: by SNPAR12.(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 4125692E.003EDC5B ; Tue, 1 Aug 2000 12:26:36 +0100 X-Lotus-FromDomain: BANQUE INDOSUEZ To: 9fans@cse.psu.edu Message-ID: <4125692E.003EDB87.00@SNPAR12.> Date: Tue, 1 Aug 2000 12:23:24 +0200 Subject: [9fans] Re: ftpfs Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu hmm my reply seems have been truncated. here it is again: i made a deliberate decision when i wrote ftpnfs (ie. ftpfs glued onto NFS. it was not pretty, but it did work. re-writing the kernel XDR was ghastly) to use the minimal number of ftp commands possible, in this way it would interoperate with more systems without code changes. with each new system the code has to be changed if you use SYST. i didn't use SYST. to determine if something was a directory i'd cd into it and if that succeeded it was a directory. if it didn't it was a file or directory you couldn't access (these i presented as files), so you didn't really care. it's LIST or NLIST (i forget which one) gives human readable output which is recomended not to be used by programs. of course my approach had the disadvantage that you didn't know the size of the file until you'd read or written it. my reasoning was that you probably knew what you were looking for and would be selective in what you opened for read. how does it go? be conservative in what you send and liberal in what you accept. does that clear things up? From owner-9fans@cse.psu.edu Tue Aug 1 08:12:10 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id IAA14781 for 9fans-outgoing; Tue, 1 Aug 2000 08:12:10 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id IAA14776 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 08:12:02 -0400 (EDT) Received: from nslocum.cs.bell-labs.com ([135.104.8.38]) by crufty; Tue Aug 1 08:11:29 EDT 2000 Received: from HWTPC (hwt-pc.cs.bell-labs.com [135.104.53.98]) by nslocum.cs.bell-labs.com (8.9.3/8.9.3) with SMTP id IAA3010387 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 08:11:29 -0400 (EDT) Message-ID: <014501bffbb1$bef147d0$62356887@HWTPC> From: "Howard Trickey" To: <9fans@cse.psu.edu> References: <200007311515.LAA18248@cse.psu.edu> <3985E318.10B7E8F8@arl.army.mil> Subject: Re: [9fans] Installing the updates Date: Tue, 1 Aug 2000 08:12:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > From: "Douglas A. Gwyn" > Since the C standard definitely requires idempotency for the > standard headers (except ), at least the APE headers > ought to conform, to ease the burden of importing non-native code. The APE headers do indeed conform. There are two stdio.h's; the one in /sys/include is for the "plan 9 way" of programming (no include protection), and the one in /sys/include/ape is for importing non-native code. From owner-9fans@cse.psu.edu Tue Aug 1 08:56:14 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id IAA15703 for 9fans-outgoing; Tue, 1 Aug 2000 08:56:14 -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 IAA15699 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 08:56:09 -0400 (EDT) Message-Id: <200008011256.IAA15699@cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Installing the updates From: "rob pike" Date: Tue, 1 Aug 2000 08:55:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > Since the C standard definitely requires idempotency for the > standard headers (except ), at least the APE headers > ought to conform, to ease the burden of importing non-native code. Yes, and our APE headers do conform. But ANSI C made a blunder on this one, I think. They should at least have deprecated the practice. But for the native environment, we corrected the error and did it right. Plan 9 is non-standard and proud of it. -rob From owner-9fans@cse.psu.edu Tue Aug 1 09:06:17 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id JAA16086 for 9fans-outgoing; Tue, 1 Aug 2000 09:06:17 -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 JAA16082 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 09:06:12 -0400 (EDT) Message-Id: <200008011306.JAA16082@cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Installing the updates From: "rob pike" Date: Tue, 1 Aug 2000 09:06:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu A user could have the distribution source on a CDROM and view it via a cache file server. This would store only the files that have changed - using copy on write. I suspose this could be extended to storing only the blocks that have changed, or even file diff(1) output, or wrap(8) file even... I'am not sure if this is interesting or hedious :-) This is the essence of what BSD calls union directories. -rob From owner-9fans@cse.psu.edu Tue Aug 1 09:07:51 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id JAA16240 for 9fans-outgoing; Tue, 1 Aug 2000 09:07:50 -0400 (EDT) Received: from linux.borf.com (mach249.borf.com [205.185.197.249] (may be forged)) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id JAA16233 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 09:07:43 -0400 (EDT) From: sah@borf.com Received: from localhost (sah@localhost) by linux.borf.com (8.9.3/8.9.3) with ESMTP id IAA03746 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 08:06:38 -0400 X-Authentication-Warning: linux.borf.com: sah owned process doing -bs Date: Tue, 1 Aug 2000 08:06:38 -0400 (EDT) To: 9fans@cse.psu.edu Subject: [9fans] auth server Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Greetings, When booting terminals from the network, I get the message: /dev/sd??/ctl: rc: can't open Subsequently, rio will not load. Any pointers? Sam -------------------------------------------------------------- Sam Hopkins sah@borf.com "... let us tame the savageness of man, and make gentle the life of this world." From owner-9fans@cse.psu.edu Tue Aug 1 09:10:11 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id JAA16437 for 9fans-outgoing; Tue, 1 Aug 2000 09:10:11 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from cackle.proxima.alt.za (cackle.proxima.alt.za [196.30.44.141]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id JAA16430 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 09:10:01 -0400 (EDT) Received: (from lucio@localhost) by cackle.proxima.alt.za (8.9.3/8.9.1) id PAA04895 for 9fans@cse.psu.edu; Tue, 1 Aug 2000 15:10:08 +0200 (SAST) Date: Tue, 1 Aug 2000 15:10:08 +0200 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] Installing the updates Message-ID: <20000801151007.C4605@cackle.proxima.alt.za> Reply-To: lucio@proxima.alt.za Mail-Followup-To: 9fans@cse.psu.edu References: <200008011306.JAA16082@cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <200008011306.JAA16082@cse.psu.edu>; from rob pike on Tue, Aug 01, 2000 at 09:06:08AM -0400 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu On Tue, Aug 01, 2000 at 09:06:08AM -0400, rob pike wrote: > > I'am not sure if this is interesting or hedious :-) > > This is the essence of what BSD calls union directories. > In which case, it is hideous: there are bugs lurking in union directories and filesystems (I also can't quite tell them apart, let's call them "mounts" for convenience) that _nobody_ wants to tackle. Mostly related to locking, if I'm not mistaken. ++L From owner-9fans@cse.psu.edu Tue Aug 1 09:36:02 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id JAA17296 for 9fans-outgoing; Tue, 1 Aug 2000 09:36:02 -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 JAA17292 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 09:35:57 -0400 (EDT) Message-Id: <200008011335.JAA17292@cse.psu.edu> Subject: Re: [9fans] Installing the updates From: "rob pike" Date: Tue, 1 Aug 2000 09:35:52 -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 Reply-To: 9fans@cse.psu.edu Perhaps I should explain better. The only tenable argument in favor of allowing #include files to include #include files is that a lot of software does that, so permitting it makes software easy to port. That is, I'm sure, why the ANSI C committee accepted it: it's standard practice. Nonetheless, it's a cop-out. It's a terrible practice that leads to n-squared inclusion of files, painful overwork by the C preprocessor, and a bad name for the idea of #include files in the first place. When designing the Plan 9 environment, we started with ANSI C for the language. Other than a couple of extensions to the language proper, we took ANSI C at face value. The library was also accepted pretty much as is, with a few minor differences. However, the C preprocessor was unacceptable to us because a) it was very complex; b) it had lots of new stuff designed by committee, a recipe for disaster; and c) most of the new stuff encouraged conditional compilation and other horrors we were trying to get away from. Our idea was to build a portable system, one whose software could be compiled without change - and that means without conditional compilation, since you always have to change the #ifdefs when you port; that is the very definition of config - as we changed architectures. Just architectures, not operating systems: we did not expect Plan 9 programs to be compilable on Unix systems, but we did expect a Plan 9 program that runs on a 386 to work on a SPARC, say, without change, just by compiling it. To meet that goal, we had to break with the ANSI include rules. To import external code, we (well, Howard) built a fairly strict ANSI C/POSIX environment that follows all the rules, including getting the libraries and C preprocessors to have standard behavior. If you want to import code, that's the minimum effort path. But if you want to build Plan 9 code, part of the environment is that #include files don't #include each other. That is just the way it works, like not running X or using mk instead of make or setting objtype=mips to build for the Mips. In short, the argument that existing software #includes like that so Plan 9 should is bogus, *because Plan 9 software does not*. Plan 9 is a different environment, but it's different for a reason. In the case of #include files, it's to make software easier to port and simpler to maintain. Within its own, admittedly smaller, world, it succeeds. Show me another system that builds all its software on multiple architectures without #ifdefs or config. Show me another system where I can compile on a SPARC, link on a 386, and run on a Mips. Show me another system where I can update an application for every architecture by typing the equivalent of mk installall I'd love to hear of it! But in this #ifdef, config-riddled world I don't think it exists. -rob From owner-9fans@cse.psu.edu Tue Aug 1 10:30:39 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id KAA19008 for 9fans-outgoing; Tue, 1 Aug 2000 10:30:39 -0400 (EDT) Received: from ocswall01.fda.gov ([198.77.181.7]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id KAA19004 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 10:30:30 -0400 (EDT) Received: from sch1.nctr.fda.gov by ocswall01.fda.gov via smtpd (for claven.cse.psu.edu [130.203.3.50]) with SMTP; 1 Aug 2000 14:27:29 UT Received: from localhost (sharris@localhost) by sch1.NCTR.FDA.GOV (8.9.3/8.9.3) with ESMTP id JAA20916 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 09:30:56 -0500 X-Authentication-Warning: sch1.NCTR.FDA.GOV: sharris owned process doing -bs Date: Tue, 1 Aug 2000 09:30:55 -0500 (CDT) From: Stephen Harris To: 9fans@cse.psu.edu Subject: [9fans] pipefile with regular file Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Pipefile is great, it's simple and I like how it uses namespace ability of Plan9 to give us a read "stream filter" which later apps don't need to even know about. But I am having a problem with reads on a filtered regular file not ever hitting EOF: (this is from memory:) pipefile -r 'tr a-z A-Z' myfile cat myfile (uppercase text to the terminal, but no prompt) I had to kill the cat with :-o Same thing if I redirect the cat to a file, have to kill it with . I thought it would go like: i ) tr eventually hits EOF ii) tr exits as last writer on internal pipe (data1) supplying data to be read by clients (cat) reading myfile iii) cat reads the remaining data if any and then hits EOF (there being no more writers), and exits. Anybody see why that's not happening, or does it work for you? Steve Everything you do from now on will be more fun - Windows 95 installation From owner-9fans@cse.psu.edu Tue Aug 1 10:38:56 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id KAA19508 for 9fans-outgoing; Tue, 1 Aug 2000 10:38:56 -0400 (EDT) Received: from linux.borf.com (mach249.borf.com [205.185.197.249] (may be forged)) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id KAA19501 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 10:38:51 -0400 (EDT) From: sah@borf.com Received: from localhost (sah@localhost) by linux.borf.com (8.9.3/8.9.3) with ESMTP id JAA03829 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 09:37:52 -0400 X-Authentication-Warning: linux.borf.com: sah owned process doing -bs Date: Tue, 1 Aug 2000 09:37:52 -0400 (EDT) To: 9fans@cse.psu.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Thanks to forsyth, the terms are up and running. Three cheers. Now I need to connect to the V2 fs to transfer important files over to V3 so we can complete the 'upgrade.' Attempts of 9fs to our V2 fs via a V3 term return "mount: mount bootes: attach -- authentication failed." Also, the V2 fs states "bad AuthTs num." The passwords and usernames are identical on both systems. So close I can taste it, Sam -------------------------------------------------------------- Sam Hopkins sah@borf.com "... let us tame the savageness of man, and make gentle the life of this world." From owner-9fans@cse.psu.edu Tue Aug 1 10:53:45 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id KAA19988 for 9fans-outgoing; Tue, 1 Aug 2000 10:53:45 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from cackle.proxima.alt.za (cackle.proxima.alt.za [196.30.44.141]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id KAA19971 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 10:53:36 -0400 (EDT) Received: (from lucio@localhost) by cackle.proxima.alt.za (8.9.3/8.9.1) id QAA05012 for 9fans@cse.psu.edu; Tue, 1 Aug 2000 16:53:43 +0200 (SAST) Date: Tue, 1 Aug 2000 16:53:42 +0200 From: Lucio De Re To: 9fans@cse.psu.edu Subject: [9fans] Re: your mail Message-ID: <20000801165341.F4605@cackle.proxima.alt.za> Reply-To: lucio@proxima.alt.za Mail-Followup-To: 9fans@cse.psu.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: ; from sah@borf.com on Tue, Aug 01, 2000 at 09:37:52AM -0400 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu On Tue, Aug 01, 2000 at 09:37:52AM -0400, sah@borf.com wrote: > > Now I need to connect to the V2 fs to transfer important files over to > V3 so we can complete the 'upgrade.' Attempts of 9fs to our V2 fs via a > V3 term return "mount: mount bootes: attach -- authentication failed." > Also, the V2 fs states "bad AuthTs num." The passwords and usernames are > identical on both systems. > I'm running very successfully with 2ed AUTH and FS. CPUs are somewhat confused, and I can't quite get the 2ed AUTH to execute the mail stuff on a 3ed CPU :-( On the other hand, I'm not sure how a 2ed FS would handle 3ed AUTH, which may be your problem. Between a rock and a hard place, like me. It may of course be merely a question of making sure AUTH and FS are in the right type of sync, which presumably means the same password for the FS and the AUTH uid. I'll enable AUTH on the 3ed CPU server a little later, see what confusion I can create. In the meantime... > So close I can taste it, > ... I think you just need a slightly longer tongue, that's all :-) ++L From owner-9fans@cse.psu.edu Tue Aug 1 10:54:48 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id KAA20098 for 9fans-outgoing; Tue, 1 Aug 2000 10:54:47 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id KAA20067 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 10:54:21 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13JdAk-0003r5-00 for 9fans@cse.psu.edu; Tue, 01 Aug 2000 15:37:34 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Tue, 1 Aug 2000 14:31:24 GMT From: Ralph Corderoy Message-ID: <8m6dhf$74d$1@inputplus.demon.co.uk> Organization: InputPlus Ltd. References: <200007311515.LAA18248@cse.psu.edu>, <3985E318.10B7E8F8@arl.army.mil> Subject: Re: [9fans] Installing the updates Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Hi, > rob pike wrote: > > Seriously, we deliberately refused to buy into that multiple > > inclusion dance, which is a hideous non-solution for the problem of > > undefined dependency order on #includes. Why not use the occasion > > to clean up the code so you only include once? > > ... > > Many developers take the approach that each interface header should > be self-contained, so that the user of the header doesn't need to > know anything about the details of the implementation of that header. > Information hiding, you know. I think he's heard the argument but doesn't agree. "Simple rule: include files should never include include files." -- http://www.lysator.liu.se/c/pikestyle.html It's well worth a read if you haven't already. (The document is a sane view in a profession contorted by ridculous company coding standards that forbid short variable names and insist on `add 1 to the object's reference counter' comments. Normally also the place where code reviews are a farce where everyone tries to detect a couple of spelling errors, even the same spelling errors as everyone else, so they can show they studied the code.) Ralph. From owner-9fans@cse.psu.edu Tue Aug 1 11:12:20 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id LAA20883 for 9fans-outgoing; Tue, 1 Aug 2000 11:12:20 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from vivido.hci-net ([212.240.227.6]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id LAA20876 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 11:12:14 -0400 (EDT) From: forsyth@vitanuova.com Message-Id: <200008011512.LAA20876@cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: your mail Date: Tue, 1 Aug 2000 16:13:02 0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu at vita nuova we run the 3rd edition on cpu server, cpu/auth server, and many terminals with a second edition file server kernel, with authentication but without fuss. i'm fairly sure i did not need to change anything. From owner-9fans@cse.psu.edu Tue Aug 1 12:03:54 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id MAA22797 for 9fans-outgoing; Tue, 1 Aug 2000 12:03:53 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from egyptian-gods.MIT.EDU (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id MAA22793 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 12:03:49 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.MIT.EDU (8.9.3) id MAA05857; Tue, 1 Aug 2000 12:03:38 -0400 Message-Id: <200008011603.MAA05857@egyptian-gods.MIT.EDU> To: 9fans@cse.psu.edu Subject: Re: [9fans] Installing the updates In-Reply-To: Your message of "Tue, 01 Aug 2000 14:31:24 GMT." <8m6dhf$74d$1@inputplus.demon.co.uk> Date: Tue, 01 Aug 2000 12:03:38 -0400 From: Greg Hudson Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > I think he's heard the argument but doesn't agree. It would be nice if Pike could present a compelling argument. His web page states only: Multiple inclusions are a bane of systems programming. It's not rare to have files included five or more times to compile a single C source file. The Unix /usr/include/sys stuff is terrible this way. Where's the horror here? Computers are fast. Pushing extra work on programmers and creating an unnecessary portability issue is a high cost. Reading a header file five or more times during compilation is a low cost (and one which can be optimized away for ifdef-protected headers; I'm told gcc does so). From owner-9fans@cse.psu.edu Tue Aug 1 12:27:08 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id MAA23570 for 9fans-outgoing; Tue, 1 Aug 2000 12:27:07 -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 MAA23565 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 12:27:02 -0400 (EDT) Message-Id: <200008011627.MAA23565@cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Installing the updates From: "rob pike" Date: Tue, 1 Aug 2000 12:26:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > It would be nice if Pike could present a compelling argument. His web > page states only: [The `web page' is just a very old class handout that propagated far beyond its intended audience.] My long note earlier today was supposed to explain better. Here's a short version: Avoid complexity. Flat structures are simpler than nested ones: simpler to write and, more important, simpler to maintain. If that doesn't compel you, I have nothing more to say. As I said, in our world, our rules work well. We cope with outside software by following outside rules. I do not expect the world to switch to our way of handling #includes; I merely ask that people writing code for Plan 9 try the Plan 9 way. -rob From owner-9fans@cse.psu.edu Tue Aug 1 12:27:23 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id MAA23610 for 9fans-outgoing; Tue, 1 Aug 2000 12:27:23 -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 MAA23591 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 12:27:13 -0400 (EDT) Message-Id: <200008011627.MAA23591@cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Installing the updates From: "rob pike" Date: Tue, 1 Aug 2000 12:27:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > I think he's heard the argument but doesn't agree. > > "Simple rule: include files should never include include files." > -- http://www.lysator.liu.se/c/pikestyle.html > Yup. That little note, written for a CS class in 1987, has been expanded into a book, published last year, called The Practice of Programming. -rob From owner-9fans@cse.psu.edu Tue Aug 1 12:32:42 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id MAA24058 for 9fans-outgoing; Tue, 1 Aug 2000 12:32:42 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from aubrey.stanford.edu (aubrey.Stanford.EDU [171.64.31.58]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id MAA24052 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 12:32:36 -0400 (EDT) Message-Id: <200008011632.MAA24052@cse.psu.edu> Received: (qmail 21642 invoked from network); 1 Aug 2000 16:32:35 -0000 Received: from localhost.highwire.org (HELO aubrey.stanford.edu) (127.0.0.1) by localhost.highwire.org with SMTP; 1 Aug 2000 16:32:35 -0000 X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: 9fans@cse.psu.edu Subject: Re: [9fans] Installing the updates In-reply-to: Message from Greg Hudson of "Tue, 01 Aug 2000 12:03:38 EDT."References: <200008011603.MAA05857@egyptian-gods.MIT.EDU> <200008011603.MAA05857@egyptian-gods.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21635.965147555.1@aubrey.stanford.edu> Date: Tue, 01 Aug 2000 09:32:35 -0700 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > It would be nice if Pike could present a compelling argument. > [...] > Where's the horror here? Computers are fast. Pushing extra work on > programmers and creating an unnecessary portability issue is a high > cost. Reading a header file five or more times during compilation is > a low cost (and one which can be optimized away for ifdef-protected > headers; I'm told gcc does so). The horror is that many header files don't get 'the dance' right. Even OS header files are screwed up sometimes. Before I read Notes on Programming in C I had put all #include calls into my program's local header file because that was how I had always seen it done. When I started writing libraries, I found all kinds of problems with the compiler complaining about multiple definitions (both my own and the system headers). I think it even makes good sense from an interface perspective. The header file shows the interface for program file. The program should hide all the implementation details, which means you shouldn't be able to tell which system calls the program makes to get the job done. Realizing that you keep including the same files may also force an eye toward keeping solid boundries across the different files (one does x, and only x. The next only handles y). Of course, if the file hides a bad job (say, calls to strtok(2)) then you're screwed anyway. Why do people object to this rule? It's not hard to follow, right? It's really not that much extra work, in my opinion. Of course there are a few that always get included, stdlib for example, but I've found only a few overlaps in a library I've just written. It's spread over 9 files, and you can see that there isn't *that* much overlap: ; grep '#include' *.c|cut -d: -f2|sort|uniq -c|sort -nr 8 #include 5 #include 5 #include 5 #include 4 #include 4 #include 4 #include 4 #include 4 #include 2 #include 2 #include 2 #include 1 #include 1 #include 1 #include 1 #include 1 #include Jim From owner-9fans@cse.psu.edu Tue Aug 1 12:52:29 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id MAA24855 for 9fans-outgoing; Tue, 1 Aug 2000 12:52:28 -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 MAA24851 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 12:52:24 -0400 (EDT) Message-Id: <200008011652.MAA24851@cse.psu.edu> Received: from ovid.cs.bell-labs.com ([135.104.50.34]) by plan9; Tue Aug 1 12:52:21 EDT 2000 To: 9fans@cse.psu.edu Subject: Re: [9fans] auth server From: "Russ Cox" Date: Tue, 1 Aug 2000 12:52:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu sorry, i thought i had fixed that. the problem is it doesn't see any disks. the example in prep(8) is correct. update /rc/bin/termrc to use the same. russ From owner-9fans@cse.psu.edu Tue Aug 1 13:05:13 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id NAA25411 for 9fans-outgoing; Tue, 1 Aug 2000 13:05:13 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from aubrey.stanford.edu (aubrey.Stanford.EDU [171.64.31.58]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id NAA25397 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 13:05:07 -0400 (EDT) Message-Id: <200008011705.NAA25397@cse.psu.edu> Received: (qmail 23573 invoked from network); 1 Aug 2000 17:05:05 -0000 Received: from localhost.highwire.org (HELO aubrey.stanford.edu) (127.0.0.1) by localhost.highwire.org with SMTP; 1 Aug 2000 17:05:05 -0000 X-url: http://highwire.stanford.edu/~jimr/ X-face: "!ZH^<"U,NeU:732A To: 9fans@cse.psu.edu Subject: Re: [9fans] Installing the updates In-reply-to: Message from "James A. Robinson" of "Tue, 01 Aug 2000 09:32:35 PDT."References: <200008011632.MAA24052@cse.psu.edu> <200008011632.MAA24052@cse.psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23566.965149505.1@aubrey.stanford.edu> Date: Tue, 01 Aug 2000 10:05:05 -0700 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Here's an even better example. Rob's sam distribution: note how the system headers are only called once. ; grep '#include' *.c|cut -d: -f2|sort|uniq -c|sort -nr 19 #include "sam.h" 4 #include "parse.h" 2 #include "config.h" 1 #include 1 #include 1 #include 1 #include 1 #include 1 #include 1 #include 1 #include 1 #include "sam.h" From owner-9fans@cse.psu.edu Tue Aug 1 13:07:19 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id NAA25581 for 9fans-outgoing; Tue, 1 Aug 2000 13:07: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 NAA25570 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 13:07:06 -0400 (EDT) Message-Id: <200008011707.NAA25570@cse.psu.edu> Received: from ovid.cs.bell-labs.com ([135.104.50.34]) by plan9; Tue Aug 1 13:06:52 EDT 2000 To: 9fans@cse.psu.edu Subject: Re: [9fans] Installing the updates From: "Russ Cox" Date: Tue, 1 Aug 2000 13:06:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Where's the horror here? Computers are fast. Pushing extra work on programmers and creating an unnecessary portability issue is a high cost. Reading a header file five or more times during compilation is a low cost (and one which can be optimized away for ifdef-protected headers; I'm told gcc does so). While it may be simpler when it works, when it fails it does so in mysterious ways. I don't know how many times I've tried to figure out why some header file I wanted wasn't getting included, only to find that it had _already_ been included, by someone else, with different things #defined, so the definition or prototype_I_ wanted wasn't there. I'd much rather have the compiler barf on a #define or something like that, than hop over the whole file as though it weren't there. Russ From owner-9fans@cse.psu.edu Tue Aug 1 14:34:29 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id OAA28725 for 9fans-outgoing; Tue, 1 Aug 2000 14:34:29 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from small-gods.mit.edu (SMALL-GODS.MIT.EDU [18.18.1.55]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id OAA28716 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 14:34:23 -0400 (EDT) Received: (from ghudson@localhost) by small-gods.mit.edu (8.9.3) id OAA28649; Tue, 1 Aug 2000 14:34:21 -0400 (EDT) Message-Id: <200008011834.OAA28649@small-gods.mit.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Installing the updates In-Reply-To: Your message of "Tue, 01 Aug 2000 09:35:52 EDT." <200008011335.JAA17292@cse.psu.edu> Date: Tue, 01 Aug 2000 14:34:21 -0400 From: Greg Hudson Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > but we did expect a Plan 9 program that runs on a 386 to work on a > SPARC, say, without change, just by compiling it. [...] > Show me another system that builds all its software on multiple > architectures without #ifdefs or config. I don't see what the big deal here is. Processor architecture has never been a big source of portability problems for Unix software. Software has to actually go and do something weird to uncover a portability problem relating to the hardware platform. It's true, some software does weird stuff (playing fast and loose with representations of integers, or having native assembly code to speed up certain operations), but it's not the majority of software and such software would presumably have the same problems doing those things on different architectures all running Plan 9. Portability problems arise mainly from operating systems, not from processors. I also don't see what this has to do with multiple include protection and headers including other headers. With regard to that issue, I'm fine with the Plan 9 designers making the choice they made, but it puzzles me when I see statements like this one: It's a terrible practice that leads to n-squared inclusion of files, painful overwork by the C preprocessor, and a bad name for the idea of #include files in the first place. which dramatically overstate the (largely nonexistent) problems resulting from the alternative. From owner-9fans@cse.psu.edu Tue Aug 1 15:10:08 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id PAA00061 for 9fans-outgoing; Tue, 1 Aug 2000 15:10:08 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from smtp3.fas.harvard.edu (root@smtp3.fas.harvard.edu [140.247.30.83]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id PAA00055 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 15:10:01 -0400 (EDT) Received: from poodle-pc.deas.harvard.edu (poodle-pc.deas.harvard.edu [140.247.51.128]) by smtp3.fas.harvard.edu with SMTP id PAA15275 Message-Id: <200008011909.PAA15275@smtp3.fas.harvard.edu> To: 9fans@cse.psu.edu, ancipites@earthlink.net Subject: Re: [9fans] problems From: "Russ Cox" Date: Tue, 1 Aug 2000 15:09:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu 1. My printer's paper tray doesn't hold enough sheets to print the manuals. It looks as though, in devlpt.c, that outch() doesn't check for Fpe when it finds an error. This was encountered when trying to print vol1.ps. That has always annoyed me. If you tell me what the code should be I'll fix it. Russ From owner-9fans@cse.psu.edu Tue Aug 1 15:23:43 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id PAA00636 for 9fans-outgoing; Tue, 1 Aug 2000 15:23:43 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from whitecrow.demon.co.uk (root@whitecrow.demon.co.uk [194.222.126.246]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id PAA00628 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 15:23:37 -0400 (EDT) Received: from whitecrow.demon.co.uk (steve@localhost [127.0.0.1]) by whitecrow.demon.co.uk (8.8.7/8.8.7) with ESMTP id IAA13373 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 08:14:12 +0100 Message-Id: <200008010714.IAA13373@whitecrow.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: 9fans@cse.psu.edu Subject: Re: [9fans] The IPv6 in Plan9 In-reply-to: Your message of "Tue, 01 Aug 2000 06:18:43 +0200." <20000801061843.E2173@cackle.proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Aug 2000 08:14:11 +0200 From: Steve Kilbane Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu On Mon, Jul 31, 2000 at 11:14:54AM -0400, presotto@plan9.bell-labs.com wrote: > > I started an ipv6 stack and got disgusted. I decided I'ld wait until there > was someone worth talking to using it to finish. i've sometimes wondered whether having an optional IPv6 stack would be a good way to get further penetration of Plan 9 (or whatever OS you implement it on): offering the box's functionality as a ready-made IPv6 backbone system. To increase the user base, users have to want something that they can't get elsewhere, and IPv6 is the main example of something that _everyone_ might want, at some point. Most other wide-scale wants are wishy-washy terms, like "e-commerce" and "micropayments." (but strangely, not "security") 'Course, the fact that they don't want it _yet_ is telling. steve From owner-9fans@cse.psu.edu Tue Aug 1 15:31:12 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id PAA01042 for 9fans-outgoing; Tue, 1 Aug 2000 15:31:11 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id PAA01027 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 15:31:00 -0400 (EDT) Received: (qmail 7206863 invoked from network); 1 Aug 2000 19:30:58 -0000 Received: from r198m3.cybercable.tm.fr (HELO coma) ([195.132.198.3]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for <9fans@cse.psu.edu>; 1 Aug 2000 19:30:58 -0000 Message-ID: <017a01bffbef$28ec6600$03c684c3@psychobasketcase.org> Reply-To: "Boyd Roberts" From: "Boyd Roberts" To: <9fans@cse.psu.edu> References: <200008010714.IAA13373@whitecrow.demon.co.uk> Subject: Re: [9fans] The IPv6 in Plan9 Date: Tue, 1 Aug 2000 21:31:58 +0200 Organization: Psycho Basket Case Outpatients Cllinic MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu From: Steve Kilbane > To increase the user base, users have to want something that they can't get > elsewhere, and IPv6 is the main example of something that _everyone_ might > want, at some point. Most other wide-scale wants are wishy-washy terms, > like "e-commerce" and "micropayments." (but strangely, not "security") > > 'Course, the fact that they don't want it _yet_ is telling. > they want it and they just assume it's for free: i've been calling it 'lego block design' -- Boyd Roberts boyd@psycho-basket-case.org But I doubt if our present system [U.S. Army] will produce such an individual. They are too: _abrasive_, opinionated, undiplomatic, nonconformist, and effective. -- Colonel David H. Hackworth (U.S. Army, Ret.) From owner-9fans@cse.psu.edu Tue Aug 1 15:38:01 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id PAA01384 for 9fans-outgoing; Tue, 1 Aug 2000 15:38:00 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from thunderer.cnchost.com (thunderer.concentric.net [207.155.252.72]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id PAA01380 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 15:37:54 -0400 (EDT) Received: from namaste.stricca.org (discordia-asy-83.rutgers.edu [128.6.251.83]) by thunderer.cnchost.com id PAA11057; Tue, 1 Aug 2000 15:37:47 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-ID: <200008011937.PAA11057@thunderer.cnchost.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] The IPv6 in Plan9 FROM: pip@namaste.stricca.org REPLY-TO: pip@stricca.org Date: Tue, 1 Aug 2000 19:42:10 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-cxbvixsbspepjbausknufnrhse" Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu This is a multi-part message in MIME format. --upas-cxbvixsbspepjbausknufnrhse Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Not to be a spoil-sport, but OpenBSD has been shipping with IPv6 support built-in for the last 2 releases. That said, I think Plan 9 is a much more enjoyable platform for experimentation, both for prospective adopters of IPv6 and for protocol implementers. - pip --upas-cxbvixsbspepjbausknufnrhse Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from cse.psu.edu (claven.cse.psu.edu [130.203.3.50]) by invincible.cnchost.com id PAA05952; Tue, 1 Aug 2000 15:24:30 -0400 (EDT) [ConcentricHost SMTP MX 1.15] Errors-To: Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) with SMTP id PAA00659; Tue, 1 Aug 2000 15:23:51 -0400 (EDT) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Tue, 1 Aug 2000 15:23:48 -0400 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id PAA00636 for 9fans-outgoing; Tue, 1 Aug 2000 15:23:43 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from whitecrow.demon.co.uk (root@whitecrow.demon.co.uk [194.222.126.246]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id PAA00628 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 15:23:37 -0400 (EDT) Received: from whitecrow.demon.co.uk (steve@localhost [127.0.0.1]) by whitecrow.demon.co.uk (8.8.7/8.8.7) with ESMTP id IAA13373 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 08:14:12 +0100 Message-Id: <200008010714.IAA13373@whitecrow.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: 9fans@cse.psu.edu Subject: Re: [9fans] The IPv6 in Plan9 In-reply-to: Your message of "Tue, 01 Aug 2000 06:18:43 +0200." <20000801061843.E2173@cackle.proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Aug 2000 08:14:11 +0200 From: Steve Kilbane Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk On Mon, Jul 31, 2000 at 11:14:54AM -0400, presotto@plan9.bell-labs.com wrote: > > I started an ipv6 stack and got disgusted. I decided I'ld wait until there > was someone worth talking to using it to finish. i've sometimes wondered whether having an optional IPv6 stack would be a good way to get further penetration of Plan 9 (or whatever OS you implement it on): offering the box's functionality as a ready-made IPv6 backbone system. To increase the user base, users have to want something that they can't get elsewhere, and IPv6 is the main example of something that _everyone_ might want, at some point. Most other wide-scale wants are wishy-washy terms, like "e-commerce" and "micropayments." (but strangely, not "security") 'Course, the fact that they don't want it _yet_ is telling. steve --upas-cxbvixsbspepjbausknufnrhse-- From owner-9fans@cse.psu.edu Tue Aug 1 16:09:25 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id QAA02331 for 9fans-outgoing; Tue, 1 Aug 2000 16:09:25 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id QAA02326 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 16:09:18 -0400 (EDT) Received: (qmail 7255192 invoked from network); 1 Aug 2000 20:09:05 -0000 Received: from r198m3.cybercable.tm.fr (HELO coma) ([195.132.198.3]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for <9fans@cse.psu.edu>; 1 Aug 2000 20:09:05 -0000 Message-ID: <019c01bffbf4$7c2429c0$03c684c3@psychobasketcase.org> Reply-To: "Boyd Roberts" From: "Boyd Roberts" To: <9fans@cse.psu.edu> References: <200008011909.PAA15275@smtp3.fas.harvard.edu> Subject: [9fans] nvram etc Date: Tue, 1 Aug 2000 22:10:05 +0200 Organization: Psycho Basket Case Outpatients Cllinic MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu why does the pc install depend on all this serious auth stuff? i can understand that you want maintain a small code base, but from a base level install who cares about all that auth nonsense. look at kfscmd. -- Boyd Roberts boyd@psycho-basket-case.org But I doubt if our present system [U.S. Army] will produce such an individual. They are too: _abrasive_, opinionated, undiplomatic, nonconformist, and effective. -- Colonel David H. Hackworth (U.S. Army, Ret.) From owner-9fans@cse.psu.edu Tue Aug 1 16:15:35 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id QAA02627 for 9fans-outgoing; Tue, 1 Aug 2000 16:15:35 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ohio.river.org (river.org [209.24.233.15]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id QAA02619 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 16:15:29 -0400 (EDT) Received: (from ru@localhost) by ohio.river.org (8.9.3/8.9.3) id NAA28249; Tue, 1 Aug 2000 13:15:28 -0700 (PDT) Date: Tue, 1 Aug 2000 13:15:28 -0700 (PDT) Message-Id: <200008012015.NAA28249@ohio.river.org> From: Richard To: 9fans@cse.psu.edu Subject: Re: [9fans] caching/overlay/union filesystem In-Reply-To: <200008011306.JAA16082@cse.psu.edu> References: <200008011306.JAA16082@cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu rob pike writes: > A user could have the distribution source on a CDROM and view it via a > cache file > server. This would store only the files that have changed - using copy > on write. > I suspose this could be extended to storing only the blocks that have > changed, or > even file diff(1) output, or wrap(8) file even... > >This is the essence of what BSD calls union directories. and what Linux calls the Overlay File System, which hasnt been updated for 2 years. http://home.att.net/~artnaseef/ovlfs/ovlfs.html Russ Cox writes: >If you had such a thing, you could try out >new wrap updates by doing > > gunzip < /tmp/new.9gz >/tmp/new.9 > archfs /tmp/new.9 > stitch -b /tmp/new.9 / another applications: many of us working at home get most of our software off of CDs. it is wasteful to back up this stuff because one can install it again from CD very easily and the CD's are even replaceable in case one loses one. and yet most of us have made small changes and additions to this stuff. most of those changes and additions can be restricted to one's home directory or /etc and thus be kept separate from the stuff from CD, but some changes have to go into eg /usr/lib/terminfo/ (excuse the Unixiness of this example). by keeping the "underlying" filesystem "pristine" (like it was right after installing from the CD) and by keeping all local changes in an overlay filesystem, one can back up just the local changes. this makes backup archives much much smaller, often letting you get by with backing up onto zip drives or CDRWs or even to the Internet rather than to tape (saving the cost of a tape drive). From owner-9fans@cse.psu.edu Tue Aug 1 16:31:28 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id QAA03177 for 9fans-outgoing; Tue, 1 Aug 2000 16:31:28 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from smtp1.fas.harvard.edu (root@smtp1.fas.harvard.edu [140.247.30.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id QAA03163 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 16:31:20 -0400 (EDT) Received: from poodle-pc.deas.harvard.edu (poodle-pc.deas.harvard.edu [140.247.51.128]) by smtp1.fas.harvard.edu with SMTP id QAA16612; Tue, 1 Aug 2000 16:31:14 -0400 (EDT) Message-Id: <200008012031.QAA16612@smtp1.fas.harvard.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] nvram etc From: "Russ Cox" Date: Tue, 1 Aug 2000 16:31:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu If you're talking about the install process, the only reason it uses an nvram file is so that there is no prompt for a user name and password, as would be the case if we had used a terminal kernel. One less thing to worry about having to explain in the installation documents. Once you've installed, the terminal doesn't use the nvram at all. I don't really understand what the problem is. Russ From owner-9fans@cse.psu.edu Tue Aug 1 16:38:03 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id QAA03468 for 9fans-outgoing; Tue, 1 Aug 2000 16:38:03 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id QAA03463 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 16:37:57 -0400 (EDT) Received: (qmail 7219253 invoked from network); 1 Aug 2000 20:37:56 -0000 Received: from r198m3.cybercable.tm.fr (HELO coma) ([195.132.198.3]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for <9fans@cse.psu.edu>; 1 Aug 2000 20:37:56 -0000 Message-ID: <01be01bffbf8$83535140$03c684c3@psychobasketcase.org> Reply-To: "Boyd Roberts" From: "Boyd Roberts" To: <9fans@cse.psu.edu> References: <200008012031.QAA16612@smtp1.fas.harvard.edu> Subject: Re: [9fans] nvram etc Date: Tue, 1 Aug 2000 22:38:56 +0200 Organization: Psycho Basket Case Outpatients Cllinic MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu ----- Original Message ----- From: Russ Cox > Once you've installed, the terminal doesn't > use the nvram at all. I don't really understand > what the problem is. the problem is when you've got an external USB floppy... From owner-9fans@cse.psu.edu Tue Aug 1 16:45:43 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id QAA03824 for 9fans-outgoing; Tue, 1 Aug 2000 16:45:43 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id QAA03816 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 16:45:34 -0400 (EDT) Received: from earthlink.net (pool0874.cvx7-bradley.dialup.earthlink.net [209.178.167.109]) by swan.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id NAA20833; Tue, 1 Aug 2000 13:45:29 -0700 (PDT) Message-ID: <39873639.951BBF88@earthlink.net> Date: Tue, 01 Aug 2000 13:42:34 -0700 From: "D. Brownlee" X-Mailer: Mozilla 4.07 (Macintosh; I; PPC) MIME-Version: 1.0 To: Russ Cox CC: 9fans@cse.psu.edu Subject: Re: [9fans] problems References: <200008011909.PAA15275@smtp3.fas.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Hello, The lpt driver is in /sys/src/9/pc/devlpt.c. That file has a function outch(): for (tries = 0;; tries++){ status = inb(base+Qpsr); if(!(status & Fselect) || !(status & Fnoerror)) Error(Eio); /* occurs when the paper tray is empty */ . . . } which might be changed to: for (tries = 0;; tries++){ status = inb(base+Qpsr); if(!(status & Fselect) || !(status & Fnoerror)) if (!(status & Fpe)) { /* paper ran out */ tries = 0; continue; } else Error(Eio); . . . } I haven't tried this -- I haven't discovered how to rebuild the kernel yet. 'Fpe' is already defined in devlpt.c. I may have the test on 'Fpe' inverted -- don't know. I think that the desired behaviour is that when the paper runs out this will wait until someone comes by and installs some paper, which should cause the 'Fpe' bit to change. That is how some other PC *nix systems behave. D. Brownlee Russ Cox wrote: > > 1. My printer's paper tray doesn't hold enough sheets to > print the manuals. It looks as though, in devlpt.c, that > outch() doesn't check for Fpe when it finds an error. This > was encountered when trying to print vol1.ps. > > That has always annoyed me. If you > tell me what the code should be I'll fix it. > > Russ From owner-9fans@cse.psu.edu Tue Aug 1 16:56:04 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id QAA04238 for 9fans-outgoing; Tue, 1 Aug 2000 16:56:03 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from smtp3.fas.harvard.edu (root@smtp3.fas.harvard.edu [140.247.30.83]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id QAA04233 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 16:55:59 -0400 (EDT) Received: from poodle-pc.deas.harvard.edu (poodle-pc.deas.harvard.edu [140.247.51.128]) by smtp3.fas.harvard.edu with SMTP id QAA29968; Tue, 1 Aug 2000 16:55:58 -0400 (EDT) Message-Id: <200008012055.QAA29968@smtp3.fas.harvard.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] nvram etc From: "Russ Cox" Date: Tue, 1 Aug 2000 16:55:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Yeah, I didn't plan far enough ahead to such situations. It was a failure of vision. There should be a way to install off a hard disk too. My apologies. If you want to build your own, you've got all the pieces. :) Russ From owner-9fans@cse.psu.edu Tue Aug 1 17:02:21 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id RAA04604 for 9fans-outgoing; Tue, 1 Aug 2000 17:02:21 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id RAA04593 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 17:02:07 -0400 (EDT) Received: (qmail 7239776 invoked from network); 1 Aug 2000 21:02:06 -0000 Received: from r198m3.cybercable.tm.fr (HELO coma) ([195.132.198.3]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for <9fans@cse.psu.edu>; 1 Aug 2000 21:02:06 -0000 Message-ID: <01d801bffbfb$e38b8d40$03c684c3@psychobasketcase.org> Reply-To: "Boyd Roberts" From: "Boyd Roberts" To: <9fans@cse.psu.edu> References: <200008012055.QAA29968@smtp3.fas.harvard.edu> Subject: Re: [9fans] nvram etc Date: Tue, 1 Aug 2000 23:03:05 +0200 Organization: Psycho Basket Case Outpatients Cllinic MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu From: Russ Cox > If you want to build your own, you've got all the pieces. :) maybe i hacked too many kernels to hack another :) From owner-9fans@cse.psu.edu Tue Aug 1 17:07:32 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id RAA04926 for 9fans-outgoing; Tue, 1 Aug 2000 17:07:32 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id RAA04917 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 17:07:25 -0400 (EDT) Received: from earthlink.net (pool0874.cvx7-bradley.dialup.earthlink.net [209.178.167.109]) by swan.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id OAA10162 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 14:07:22 -0700 (PDT) Message-ID: <39873B64.208C3E60@earthlink.net> Date: Tue, 01 Aug 2000 14:04:37 -0700 From: "D. Brownlee" X-Mailer: Mozilla 4.07 (Macintosh; I; PPC) MIME-Version: 1.0 To: 9fans@cse.psu.edu Subject: Re: [9fans] problems References: <200008011909.PAA15275@smtp3.fas.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu I recently suggested a change without knowing too much about how Plan 9 drivers work. Perhaps, when 'Fpe' is detected, 'tsleep' should be called. (wouldn't want to hang the whole system until someone adds some more paper!) Or is the driver scheduled independently? It is probably best to call 'tsleep' in any case. D. Brownlee Russ Cox wrote: > > 1. My printer's paper tray doesn't hold enough sheets to > print the manuals. It looks as though, in devlpt.c, that > outch() doesn't check for Fpe when it finds an error. This > was encountered when trying to print vol1.ps. > > That has always annoyed me. If you > tell me what the code should be I'll fix it. > > Russ From owner-9fans@cse.psu.edu Tue Aug 1 17:27:00 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id RAA05575 for 9fans-outgoing; Tue, 1 Aug 2000 17:27:00 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from smtp4.fas.harvard.edu (root@smtp4.fas.harvard.edu [140.247.30.84]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id RAA05568 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 17:26:54 -0400 (EDT) Received: from poodle-pc.deas.harvard.edu (poodle-pc.deas.harvard.edu [140.247.51.128]) by smtp4.fas.harvard.edu with SMTP id RAA30253; Tue, 1 Aug 2000 17:26:48 -0400 (EDT) Message-Id: <200008012126.RAA30253@smtp4.fas.harvard.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] problems From: "Russ Cox" Date: Tue, 1 Aug 2000 17:26:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu The right change is probably to sleep waiting for a status change interrupt as it does a little bit later; what I wondered about was the sense of Fpe and whether it actually had something to do with paper. Russ From owner-9fans@cse.psu.edu Tue Aug 1 18:50:52 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id SAA07252 for 9fans-outgoing; Tue, 1 Aug 2000 18:50:52 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id SAA07247 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 18:50:45 -0400 (EDT) Received: from earthlink.net (pool1240.cvx21-bradley.dialup.earthlink.net [209.179.196.220]) by swan.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id PAA07939 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 15:50:44 -0700 (PDT) Message-ID: <3987539D.8FC9FF37@earthlink.net> Date: Tue, 01 Aug 2000 15:48:01 -0700 From: "D. Brownlee" X-Mailer: Mozilla 4.07 (Macintosh; I; PPC) MIME-Version: 1.0 To: 9fans@cse.psu.edu Subject: Re: [9fans] problems References: <200008012126.RAA30253@smtp4.fas.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Reading from the "IBM PS/2 Hardware Technical Reference," "Parallel Port Controller (Type 1)," not necessarily an up to date or applicable document, it says, concerning the Status Port: Bit 5 This bit represents the current state of the printer 'paper end' signal (PE). When this bit is set to 1, the printer has detected the end of the paper. in contast, another bit is described: Bit 3 This bit represents the current state of the printer '-error' signal (-ERROR). When this bit is set to 0, the printer has encountered an error condition. Hope that helps, D. Brownlee Russ Cox wrote: > > The right change is probably to sleep > waiting for a status change interrupt > as it does a little bit later; what I wondered > about was the sense of Fpe and whether > it actually had something to do with paper. > > Russ From owner-9fans@cse.psu.edu Tue Aug 1 21:25:18 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id VAA09837 for 9fans-outgoing; Tue, 1 Aug 2000 21:25:18 -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 VAA09830 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 21:25:11 -0400 (EDT) From: presotto@plan9.bell-labs.com Message-Id: <200008020125.VAA09830@cse.psu.edu> Date: Tue, 1 Aug 2000 21:24:42 -0400 To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: your mail MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-krfkcpcbokuztcecumrzslttfj" Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu This is a multi-part message in MIME format. --upas-krfkcpcbokuztcecumrzslttfj Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit We changed the cpu protocol between editions. The change was to get rid of the second connection for notes. This was a good suggestion from Dave Mazieres at MIT. You can convert the 2ed cpu.c to run on 3ed. Here's the diffs: % diff cpu.c /sys/src/cmd/ocpu.c 21a22 > int filter(int); 26a28 > int fflag; 30,31c32,33 < char *srvname = "cpu"; < char *notesrv = "cpunote"; --- > char *srvname = "ocpu"; > char *notesrv = "ocpunote"; 39a42 > int fdd; 50a54,56 > case 'f': > fflag++; > break; 109a116,118 > if(fflag) > data = filter(data); > 124a134 > va_list arg; 126c136,138 < doprint(buf, buf+sizeof(buf), fmt, (&fmt+1)); --- > va_start(arg, fmt); > doprint(buf, buf+sizeof(buf), fmt, arg); > va_end(arg); 183a196 > 185c198,202 < if(amount(fd, "/mnt/term", MREPL, "") < 0) --- > > /* push fcall */ > if(fflag) > fd = filter(fd); > if(amount(fd, "/mnt/term", MCREATE|MREPL, "") < 0) 282a300 > char dir[4*NAMELEN]; 285c303 < if((*fd = dial(na, 0, 0, 0)) < 0) --- > if((*fd = dial(na, 0, dir, 0)) < 0) 288a307,308 > if(strstr(dir, "tcp")) > fflag = 1; 318a339,366 > > /* Network on fd1, mount driver on fd0 */ > int > filter(int fd) > { > int p[2]; > > if(pipe(p) < 0) > fatal(1, "pipe"); > > switch(rfork(RFNOWAIT|RFPROC|RFFDG)) { > case -1: > fatal(1, "rfork record module"); > case 0: > dup(fd, 1); > close(fd); > dup(p[0], 0); > close(p[0]); > close(p[1]); > execl("/bin/aux/fcall", "fcall", 0); > fatal(1, "exec record module"); > default: > close(fd); > close(p[0]); > } > return p[1]; > } > You also need to create the /rc/bin/service files on 3ed for the 2ed ports: % cat > /rc/bin/service/il17006 << EOF #!/bin/rc exec /bin/ocpu -R EOF % cat > /rc/bin/service/il17006 << EOF #!/bin/ocpu -N EOF % cat > /rc/bin/service/tcp17005 << EOF #!/bin/rc exec /bin/ocpu -f -R EOF % cat > /rc/bin/service/tcp17006 << EOF #!/bin/ocpu -N EOF % chmod +x /rc/bin/service/*1700[56] You can then use ocpu to get back to 2ed. I'll put these puppies in the next update. --upas-krfkcpcbokuztcecumrzslttfj Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Tue Aug 1 11:09:20 EDT 2000 Received: from cse.psu.edu ([130.203.3.50]) by plan9; Tue Aug 1 11:09:19 EDT 2000 Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) with SMTP id KAA20025; Tue, 1 Aug 2000 10:53:59 -0400 (EDT) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Tue, 1 Aug 2000 10:53:50 -0400 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id KAA19988 for 9fans-outgoing; Tue, 1 Aug 2000 10:53:45 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from cackle.proxima.alt.za (cackle.proxima.alt.za [196.30.44.141]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id KAA19971 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 10:53:36 -0400 (EDT) Received: (from lucio@localhost) by cackle.proxima.alt.za (8.9.3/8.9.1) id QAA05012 for 9fans@cse.psu.edu; Tue, 1 Aug 2000 16:53:43 +0200 (SAST) Date: Tue, 1 Aug 2000 16:53:42 +0200 From: Lucio De Re To: 9fans@cse.psu.edu Subject: [9fans] Re: your mail Message-ID: <20000801165341.F4605@cackle.proxima.alt.za> Reply-To: lucio@proxima.alt.za Mail-Followup-To: 9fans@cse.psu.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: ; from sah@borf.com on Tue, Aug 01, 2000 at 09:37:52AM -0400 Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk On Tue, Aug 01, 2000 at 09:37:52AM -0400, sah@borf.com wrote: > > Now I need to connect to the V2 fs to transfer important files over to > V3 so we can complete the 'upgrade.' Attempts of 9fs to our V2 fs via a > V3 term return "mount: mount bootes: attach -- authentication failed." > Also, the V2 fs states "bad AuthTs num." The passwords and usernames are > identical on both systems. > I'm running very successfully with 2ed AUTH and FS. CPUs are somewhat confused, and I can't quite get the 2ed AUTH to execute the mail stuff on a 3ed CPU :-( On the other hand, I'm not sure how a 2ed FS would handle 3ed AUTH, which may be your problem. Between a rock and a hard place, like me. It may of course be merely a question of making sure AUTH and FS are in the right type of sync, which presumably means the same password for the FS and the AUTH uid. I'll enable AUTH on the 3ed CPU server a little later, see what confusion I can create. In the meantime... > So close I can taste it, > ... I think you just need a slightly longer tongue, that's all :-) ++L --upas-krfkcpcbokuztcecumrzslttfj-- From owner-9fans@cse.psu.edu Tue Aug 1 21:29:44 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id VAA10019 for 9fans-outgoing; Tue, 1 Aug 2000 21:29:44 -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 VAA10015 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 21:29:40 -0400 (EDT) From: presotto@plan9.bell-labs.com Message-Id: <200008020129.VAA10015@cse.psu.edu> Date: Tue, 1 Aug 2000 21:29:36 -0400 To: lucio@proxima.alt.za, 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 Reply-To: 9fans@cse.psu.edu Of course, alternately, you could port the 3ed cpu.c to 2ed. It might even be easier if you don't have a lot of 2ed stuff out there. From owner-9fans@cse.psu.edu Tue Aug 1 22:30:05 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id WAA11045 for 9fans-outgoing; Tue, 1 Aug 2000 22:30:05 -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 WAA11041 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 22:30:00 -0400 (EDT) Message-Id: <200008020230.WAA11041@cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] pipefile with regular file From: "rob pike" Date: Tue, 1 Aug 2000 22:29:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > But I am having a problem with reads on a filtered regular file not ever > hitting EOF: The kernel has a ref on the other end of the pipe because it's still available to be opened and used again. You'll never see EOF. There were a couple of missing calls to close in the code I sent, but even if you close everything in sight, you'll never see EOF. There's a twisty maze of circular dependencies holding the structure up. As I said in the beginning, this trick is suitable for continuous files such as devices, but not for regular files. -rob From owner-9fans@cse.psu.edu Tue Aug 1 23:38:55 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id XAA12162 for 9fans-outgoing; Tue, 1 Aug 2000 23:38:54 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from prognet.com (prognet.com [205.219.198.1]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id XAA12154 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 23:38:48 -0400 (EDT) Received: from user ([172.21.104.107]) by prognet.com (8.9.2/8.9.0) with SMTP id UAA10865 for <9fans@cse.psu.edu>; Tue, 1 Aug 2000 20:39:05 -0700 (PDT) Message-Id: <3.0.5.32.20000801204034.007cfe40@mail.real.com> X-Sender: skipt@mail.real.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 01 Aug 2000 20:40:34 -0700 To: 9fans@cse.psu.edu From: Skip Tavakkolian Subject: Re: [9fans] pipefile In-Reply-To: <200007310115.VAA03125@cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Could one stack pipefiles? Also, this may be a totally stupid question, but I am wondering why there never was a notation for bidirectional pipes in the shell (say '><') that sets this pipelining? So, your example would look like: rc >< readwrite /dev/cons It does look to be of limited use. At 09:14 PM 7/30/00 -0400, rob pike wrote: >> If you don't mind, could you also say a word as to what made the >> /dev/cons case special? Who was writing to /dev/cons all of the >> keyboard input so that it worked? (rio?) > >/dev/cons is connected to standard in and standard out, that's all. >I stupidly had file descriptors 0 and 1 wired into the code. >Nobody was writing any keyboard input of any kind to /dev/cons. > >What pipefile does is place filters between the file and >any subsequent program that opens it for i/o, by binding a pipe >onto the file and then connecting the filters to the pipe. The other >end of the pipe is connected to the underlying file. > >Normally you have, in effect, > > /dev/cons > >but after > > pipefile -r 'readcmd' -w 'writecmd' /dev/cons > rc < /dev/cons >/dev/cons > >you have, almost literally, > > /dev/cons > >(The only difference is that it uses one full duplex pipe instead >of two half duplex ones.) > >What was special about /dev/cons was that I had this >example in mind when I wrote the program, so what >it actually did was closer to > > /fd/1 > >The fix was to open the file explicitly. > >Hope that helps. > >-rob > > From owner-9fans@cse.psu.edu Wed Aug 2 00:40:15 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id AAA13104 for 9fans-outgoing; Wed, 2 Aug 2000 00:40:14 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from cackle.proxima.alt.za (cackle.proxima.alt.za [196.30.44.141]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id AAA13099 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 00:40:06 -0400 (EDT) Received: (from lucio@localhost) by cackle.proxima.alt.za (8.9.3/8.9.1) id GAA07055 for 9fans@cse.psu.edu; Wed, 2 Aug 2000 06:40:10 +0200 (SAST) Date: Wed, 2 Aug 2000 06:40:08 +0200 From: Lucio De Re To: 9fans mailing list <9fans@cse.psu.edu> Subject: [9fans] #include idempotency madness - compromise Message-ID: <20000802064008.A5311@cackle.proxima.alt.za> Reply-To: lucio@proxima.alt.za Mail-Followup-To: 9fans mailing list <9fans@cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu #ifdef _STDIO_H #warning "stdio.h already included" #else #endif where #warning should resolve to something useful, should please both camps (except for elegance concerns). For one, people should be allowed, not encouraged, to shoot themselves in the foot. ++L From owner-9fans@cse.psu.edu Wed Aug 2 01:37:01 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id BAA13749 for 9fans-outgoing; Wed, 2 Aug 2000 01:37:00 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id BAA13745 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 01:36:56 -0400 (EDT) From: nigel@9fs.org Received: from cotswold.demon.co.uk ([194.222.75.186] helo=blue) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 13JrD4-000KWB-0K for 9fans@cse.psu.edu; Wed, 2 Aug 2000 05:36:55 +0000 To: 9fans@cse.psu.edu Date: Wed, 2 Aug 2000 06:35:19 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: [9fans] Re: mounting Plan9 fs on linux Message-ID: <3987C127.12933.1FAAEF@localhost> In-reply-to: <200007311012.GAA11677@cse.psu.edu> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Curses. Now there's an idea. On 31 Jul 2000, at 11:13, forsyth@vitanuova.com wrote: > >Unfortunately, there is already a tool called vi, so a port of > > that's an unusual use of the word `unfortunately'. > > From owner-9fans@cse.psu.edu Wed Aug 2 01:39:12 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id BAA13883 for 9fans-outgoing; Wed, 2 Aug 2000 01:39:12 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id BAA13877 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 01:39:06 -0400 (EDT) From: nigel@9fs.org Received: from cotswold.demon.co.uk ([194.222.75.186] helo=blue) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 13JrFB-000KaI-0K for 9fans@cse.psu.edu; Wed, 2 Aug 2000 05:39:05 +0000 To: 9fans@cse.psu.edu Date: Wed, 2 Aug 2000 06:37:29 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: [9fans] Re: mounting Plan9 fs on linux Message-ID: <3987C1A9.16506.21A72C@localhost> In-reply-to: <200007311608.MAA20347@cse.psu.edu> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Yes, and also elvis, and you know what they say about Elvis. On 31 Jul 2000, at 12:08, dhog@plan9.bell-labs.com wrote: > atrn@zeta.org.au writes: > > It's okay these days, vi changed names, pick nvi or vim. > > There's also vile -- truth in advertising. > > From owner-9fans@cse.psu.edu Wed Aug 2 03:54:41 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id DAA15257 for 9fans-outgoing; Wed, 2 Aug 2000 03:54:41 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from trachyte.chigaku6.co.jp (granite.cias.osakafu-u.ac.jp [157.16.91.52]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id DAA15253 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 03:54:36 -0400 (EDT) From: okamoto@granite.cias.osakafu-u.ac.jp Message-Id: <200008020754.DAA15253@cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] pipefile Date: Wed, 2 Aug 2000 16:55:47 0900 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu >As I said in the beginning, this trick is suitable for continuous >files such as devices I was confused in my earlier mail, because I had no EARGF definition on my libc.h. Now, I got the new update, and it works now what you intended (probably). Then, now I'm wondering rightly☺ how I can end the input, and return to shell prompt, when I hit return key on rio environment. Yes, I have read rio sources, but it's beyond my ability. My only understand on this is to send nil length font length to the frame of the window of rio.... I know this procedure is simple, and works under acme, too. When I input Japanese like below: term% 日本語の入力の練習です。 I cannot now return to rc shell. Kenji From owner-9fans@cse.psu.edu Wed Aug 2 04:46:43 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA15823 for 9fans-outgoing; Wed, 2 Aug 2000 04:46:43 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from lafontaine.cybercable.fr (lafontaine.cybercable.fr [212.198.0.202]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id EAA15819 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 04:46:37 -0400 (EDT) Received: (qmail 23076793 invoked from network); 2 Aug 2000 08:46:36 -0000 Received: from r198m3.cybercable.tm.fr (HELO coma) ([195.132.198.3]) (envelope-sender ) by lafontaine.cybercable.fr (qmail-ldap-1.03) with SMTP for <9fans@cse.psu.edu>; 2 Aug 2000 08:46:36 -0000 Message-ID: <003c01bffc5c$ea5fc940$03c684c3@psychobasketcase.org> Reply-To: "Boyd Roberts" From: "Boyd Roberts" To: <9fans@cse.psu.edu> References: <3987C127.12933.1FAAEF@localhost> Subject: Re: [9fans] Re: mounting Plan9 fs on linux Date: Wed, 2 Aug 2000 10:37:38 +0200 Organization: Psycho Basket Case Outpatients Cllinic MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu From: > Curses. > Now there's an idea. i'll get right onto it. gee that code was so well written. and the interface? such elegance and simplicity. From owner-9fans@cse.psu.edu Wed Aug 2 04:47:53 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA15927 for 9fans-outgoing; Wed, 2 Aug 2000 04:47:53 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from lafontaine.cybercable.fr (lafontaine.cybercable.fr [212.198.0.202]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id EAA15918 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 04:47:44 -0400 (EDT) Received: (qmail 23152843 invoked from network); 2 Aug 2000 08:47:43 -0000 Received: from r198m3.cybercable.tm.fr (HELO coma) ([195.132.198.3]) (envelope-sender ) by lafontaine.cybercable.fr (qmail-ldap-1.03) with SMTP for <9fans@cse.psu.edu>; 2 Aug 2000 08:47:43 -0000 Message-ID: <004201bffc5d$11ca6c60$03c684c3@psychobasketcase.org> Reply-To: "Boyd Roberts" From: "Boyd Roberts" To: <9fans@cse.psu.edu> References: <3987C1A9.16506.21A72C@localhost> Subject: Re: [9fans] Re: mounting Plan9 fs on linux Date: Wed, 2 Aug 2000 10:38:44 +0200 Organization: Psycho Basket Case Outpatients Cllinic MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu From: > Yes, and also elvis, and you know what they say about Elvis. elvis has left the building -- thank god. From owner-9fans@cse.psu.edu Wed Aug 2 04:51:34 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA16135 for 9fans-outgoing; Wed, 2 Aug 2000 04:51:33 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id EAA16121 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 04:51:24 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13Ju1Q-0007P1-00 for 9fans@cse.psu.edu; Wed, 02 Aug 2000 09:37:04 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Wed, 2 Aug 2000 08:32:55 GMT From: "Bruce G. Stewart" Message-ID: <39878BDB.BFD4CEEC@worldnet.att.net> Organization: AT&T Worldnet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200008011707.NAA25570@cse.psu.edu> Reply-To: bstewart@bix.com Subject: Re: [9fans] Installing the updates Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Russ Cox wrote: > > Where's the horror here? Computers are fast. Pushing extra work on > programmers and creating an unnecessary portability issue is a high > cost. Reading a header file five or more times during compilation is > a low cost (and one which can be optimized away for ifdef-protected > headers; I'm told gcc does so). > > While it may be simpler when it works, when > it fails it does so in mysterious ways. I don't know > how many times I've tried to figure out why > some header file I wanted wasn't getting included, > only to find that it had _already_ been included, > by someone else, with different things #defined, > so the definition or prototype_I_ wanted wasn't > there. > > I'd much rather have the compiler barf on a > #define or something like that, than hop over > the whole file as though it weren't there. > > Russ I think nested includes also lead to excessive factoring - there is a folklore that says small include files are better because fewer things need to be recompiled when a header is changed. More includes makes for more interdependencies, so one resorts to nesting to reduce the amount of typing. Then one needs a tool to find all the dependencies to create the mkfile. One wants to run it whenever a header changes in case some new nested dependency has been introduced. Perhaps a mkfile to mk your mkfile is the answer.. and on it goes. I also find the one library / one h principal attractive. I'd rather have the compiler wasting its time scanning one behemoth text than scanning a lot of little files looking for #endif. From owner-9fans@cse.psu.edu Wed Aug 2 04:51:42 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA16154 for 9fans-outgoing; Wed, 2 Aug 2000 04:51:41 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id EAA16128 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 04:51:27 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13Ju1P-0007Ov-00 for 9fans@cse.psu.edu; Wed, 02 Aug 2000 09:37:03 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Wed, 2 Aug 2000 08:32:38 GMT From: "D. Brownlee" Message-ID: <398751CD.DA07B7D7@earthlink.net> Organization: EarthLink Inc. -- http://www.EarthLink.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [9fans] 'date' question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu My hardware clock is set to GMT, and Glenda's /env/timezone indicates that the 'date' command should be printing EST or EDT; however, glenda's 'date' prints "22:30:03 EDT 2000," when PDT is, by my watch, 15:30:03. It looks as though EDT is 7 hours off! If EDT were correct, I would expect it to be 18:30 when PDT is 15:30. Should the hardware clock actually be set to GMT? Later, D. Brownlee From owner-9fans@cse.psu.edu Wed Aug 2 04:51:51 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA16170 for 9fans-outgoing; Wed, 2 Aug 2000 04:51:50 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id EAA16142 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 04:51:35 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13Ju1P-0007Op-00 for 9fans@cse.psu.edu; Wed, 02 Aug 2000 09:37:03 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Wed, 2 Aug 2000 08:32:19 GMT From: "D. Brownlee" Message-ID: <39874DE1.ABE7F07E@earthlink.net> Organization: EarthLink Inc. -- http://www.EarthLink.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [9fans] perfmeter question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Is there an executable or source for the performance meter that is displayed when the installation disk is booted? Where? Later, D. Brownlee From owner-9fans@cse.psu.edu Wed Aug 2 04:57:56 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA16586 for 9fans-outgoing; Wed, 2 Aug 2000 04:57:56 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id EAA16580 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 04:57:49 -0400 (EDT) From: miller@hamnavoe.demon.co.uk Received: from hamnavoe.demon.co.uk ([158.152.225.204] helo=hamnavoe) by anchor-post-31.mail.demon.net with smtp (Exim 2.12 #1) id 13JuLT-0005k5-0V for 9fans@cse.psu.edu; Wed, 2 Aug 2000 09:57:48 +0100 To: 9fans@cse.psu.edu Subject: Re: [9fans] Kernel question: i386 test-and-set problem Date: Wed, 2 Aug 2000 09:32:59 0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > We did try your solution since it was the obious one. Wasn't obvious to me. It emerged from an attempt to sketch a correctness proof and then derive a version of the algorithm which would correspond to it. > Process p now continues after the sleep: > > process p: > sleep(r); > free(r) > > Process y now does > > xxx = malloc(234); > xxx->a = 12; > > And finally process x does its lock(r). We've just > clobbered some other processes kernel structure. Ah. It had not actually occurred to me that a kernel process might be freeing a data structure while another process still held a pointer into it. How naive of me. If the scenario above is really allowed, I don't see why it isn't just as much a problem with the existing kernel. Even without the interference of postnote(), we might have sleep(r) finding the wakeup condition true and returning immediately, so that the free(r) and malloc() could happen while or even before wakeup(r) runs. So when /sys/src/9/port/proc.c:#10217,#10286 is executed, r points to something which is no longer a Rendez structure. Therefore r->p could be anything, and the lock(&p->rlock) could clobber something or even cause a memory fault. Or am I missing something obvious again? -- Richard From owner-9fans@cse.psu.edu Wed Aug 2 05:04:07 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA16828 for 9fans-outgoing; Wed, 2 Aug 2000 05:04:07 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id FAA16824 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 05:04:02 -0400 (EDT) Received: (qmail 7545632 invoked from network); 2 Aug 2000 09:04:01 -0000 Received: from r198m3.cybercable.tm.fr (HELO coma) ([195.132.198.3]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for <9fans@cse.psu.edu>; 2 Aug 2000 09:04:01 -0000 Message-ID: <00e901bffc5f$50ef0e80$03c684c3@psychobasketcase.org> Reply-To: "Boyd Roberts" From: "Boyd Roberts" To: <9fans@cse.psu.edu> References: <398751CD.DA07B7D7@earthlink.net> Subject: Re: [9fans] 'date' question Date: Wed, 2 Aug 2000 10:54:49 +0200 Organization: Psycho Basket Case Outpatients Cllinic MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu From: D. Brownlee > Should the hardware clock actually be set to GMT? > i'm no expert, but it's pretty much a cardinal rule that the h/w clock be set to gmt. the again these PC h/w clocks pretty much suck, so it could be an exception. From owner-9fans@cse.psu.edu Wed Aug 2 05:06:40 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA17021 for 9fans-outgoing; Wed, 2 Aug 2000 05:06:40 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from liw.jme.cz (liw.jme.cz [194.212.202.210]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id FAA17014 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 05:06:34 -0400 (EDT) Received: from lix.jme.cz ([194.212.202.194]) by liw.jme.cz with Microsoft SMTPSVC(5.5.1877.197.19); Wed, 2 Aug 2000 11:06:03 +0200 Received: by lix.jme.cz with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Aug 2000 11:06:02 +0200 Message-ID: From: =?iso-8859-2?Q?Ve=E8e=F8a_Anton=EDn?= To: "'9fans@cse.psu.edu'" <9fans@cse.psu.edu> Subject: RE: [9fans] perfmeter question Date: Wed, 2 Aug 2000 11:06:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFFC60.E1D37F6C" Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFFC60.E1D37F6C Content-Type: text/plain; charset="iso-8859-2" > > Is there an executable or source for the performance meter > that is displayed when the installation disk is booted? Where? > > Later, > > D. Brownlee > there is a command "stats". A. Vecera ------_=_NextPart_001_01BFFC60.E1D37F6C Content-Type: text/html; charset="iso-8859-2" RE: [9fans] perfmeter question

>
> Is there an executable or source for the performance meter
> that is displayed when the installation disk is booted? Where?
>
> Later,
>
> D. Brownlee
>

there is a command "stats".

A. Vecera

------_=_NextPart_001_01BFFC60.E1D37F6C-- From owner-9fans@cse.psu.edu Wed Aug 2 05:09:02 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA17206 for 9fans-outgoing; Wed, 2 Aug 2000 05:09:01 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from vivido.hci-net ([212.240.227.6]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id FAA17198 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 05:08:53 -0400 (EDT) From: forsyth@vitanuova.com Message-Id: <200008020908.FAA17198@cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] 'date' question Date: Wed, 2 Aug 2000 10:09:42 0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-gqpbrgxtpggexfmxjytaqnmahq" Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu This is a multi-part message in MIME format. --upas-gqpbrgxtpggexfmxjytaqnmahq Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit you might need to eliminate the use of the -L option to timesync(8) by termrc or cpurc if your hardware clock is GMT. --upas-gqpbrgxtpggexfmxjytaqnmahq Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from punt-1.mail.demon.net by mailstore for forsyth@vitanuova.com id 965206404:10:04558:10; Wed, 02 Aug 2000 08:53:24 GMT Received: from claven.cse.psu.edu ([130.203.3.50]) by punt-1.mail.demon.net id aa1004433; 2 Aug 2000 8:53 GMT Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) with SMTP id EAA16277; Wed, 2 Aug 2000 04:52:41 -0400 (EDT) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Wed, 2 Aug 2000 04:52:04 -0400 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA16154 for 9fans-outgoing; Wed, 2 Aug 2000 04:51:41 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id EAA16128 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 04:51:27 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13Ju1P-0007Ov-00 for 9fans@cse.psu.edu; Wed, 02 Aug 2000 09:37:03 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: cse.psu.edu!9fans Date: Wed, 2 Aug 2000 08:32:38 GMT Message-ID: <398751CD.DA07B7D7@earthlink.net> Organization: EarthLink Inc. -- http://www.EarthLink.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [9fans] 'date' question Sender: cse.psu.edu!owner-9fans Reply-To: cse.psu.edu!9fans Precedence: bulk My hardware clock is set to GMT, and Glenda's /env/timezone indicates that the 'date' command should be printing EST or EDT; however, glenda's 'date' prints "22:30:03 EDT 2000," when PDT is, by my watch, 15:30:03. It looks as though EDT is 7 hours off! If EDT were correct, I would expect it to be 18:30 when PDT is 15:30. Should the hardware clock actually be set to GMT? Later, D. Brownlee --upas-gqpbrgxtpggexfmxjytaqnmahq-- From owner-9fans@cse.psu.edu Wed Aug 2 05:11:09 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA17372 for 9fans-outgoing; Wed, 2 Aug 2000 05:11:09 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from vivido.hci-net ([212.240.227.6]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id FAA17358 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 05:10:58 -0400 (EDT) From: forsyth@vitanuova.com Message-Id: <200008020910.FAA17358@cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] perfmeter question Date: Wed, 2 Aug 2000 10:11:48 0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-usysetxyzlftdizsuyqjfpvlbs" Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu This is a multi-part message in MIME format. --upas-usysetxyzlftdizsuyqjfpvlbs Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit stats(8) ? --upas-usysetxyzlftdizsuyqjfpvlbs Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from punt-1.mail.demon.net by mailstore for forsyth@vitanuova.com id 965206498:10:06834:32; Wed, 02 Aug 2000 08:54:58 GMT Received: from claven.cse.psu.edu ([130.203.3.50]) by punt-1.mail.demon.net id aa1006658; 2 Aug 2000 8:54 GMT Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) with SMTP id EAA16324; Wed, 2 Aug 2000 04:53:09 -0400 (EDT) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Wed, 2 Aug 2000 04:52:23 -0400 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA16170 for 9fans-outgoing; Wed, 2 Aug 2000 04:51:50 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id EAA16142 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 04:51:35 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13Ju1P-0007Op-00 for 9fans@cse.psu.edu; Wed, 02 Aug 2000 09:37:03 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: cse.psu.edu!9fans Date: Wed, 2 Aug 2000 08:32:19 GMT Message-ID: <39874DE1.ABE7F07E@earthlink.net> Organization: EarthLink Inc. -- http://www.EarthLink.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [9fans] perfmeter question Sender: cse.psu.edu!owner-9fans Reply-To: cse.psu.edu!9fans Precedence: bulk Is there an executable or source for the performance meter that is displayed when the installation disk is booted? Where? Later, D. Brownlee --upas-usysetxyzlftdizsuyqjfpvlbs-- From owner-9fans@cse.psu.edu Wed Aug 2 05:21:24 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA17678 for 9fans-outgoing; Wed, 2 Aug 2000 05:21:23 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id FAA17671 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 05:21:16 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13JuZs-0007lX-00 for 9fans@cse.psu.edu; Wed, 02 Aug 2000 10:12:40 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Wed, 2 Aug 2000 09:11:37 GMT From: "Douglas A. Gwyn" Message-ID: <3987E345.4B8F3643@home.com> Organization: @Home Network Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200007311515.LAA18248@cse.psu.edu>, <014501bffbb1$bef147d0$62356887@HWTPC> Reply-To: DAGwyn@null.net Subject: Re: [9fans] Installing the updates Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > The APE headers do indeed conform. Okay, problem solved. The Plan9 native headers can certainly do whatever Rob and crew think is best. We already know that it is non-trivial to port much non-Plan9 code to Plan9-native and vice versa. From owner-9fans@cse.psu.edu Wed Aug 2 05:21:28 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA17689 for 9fans-outgoing; Wed, 2 Aug 2000 05:21:28 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id FAA17677 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 05:21:21 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13JuZs-0007lR-00 for 9fans@cse.psu.edu; Wed, 02 Aug 2000 10:12:40 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Wed, 2 Aug 2000 09:11:19 GMT From: "Douglas A. Gwyn" Message-ID: <3987E2C2.7C73A4D7@home.com> Organization: @Home Network Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200007311515.LAA18248@cse.psu.edu>, <3985E318.10B7E8F8@arl.army.mil>, <8m6dhf$74d$1@inputplus.demon.co.uk> Reply-To: DAGwyn@null.net Subject: Re: [9fans] Installing the updates Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Ralph Corderoy wrote: > > Many developers take the approach that each interface header should > > be self-contained, so that the user of the header doesn't need to > > know anything about the details of the implementation of that header. > > Information hiding, you know. > I think he's heard the argument but doesn't agree. > -- http://www.lysator.liu.se/c/pikestyle.html > (The document is a sane view in a profession contorted by ridculous > company coding standards that forbid short variable names and insist on > `add 1 to the object's reference counter' comments. Normally also the > place where code reviews are a farce where everyone tries to detect a > couple of spelling errors, even the same spelling errors as everyone > else, so they can show they studied the code.) I wasn't saying that *either* approach is always best, just that there could be solid reasons why the standard headers need to be idempotent as specified. Making interface headers self-contained is hardly in the same category as the "coding standards" you cite. From owner-9fans@cse.psu.edu Wed Aug 2 05:42:47 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA18211 for 9fans-outgoing; Wed, 2 Aug 2000 05:42:47 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id FAA18205 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 05:42:41 -0400 (EDT) Received: from symnt3.Cadence.COM (symnt3.Cadence.COM [194.32.101.100]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id CAA04460 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 02:42:39 -0700 (PDT) Received: from pc535-cam (pc535-cam.cadence.com [194.32.97.87]) by symnt3.Cadence.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id PH3AA1AW; Wed, 2 Aug 2000 10:39:55 +0100 From: "Nigel Roles" To: 9fans@cse.psu.edu Date: Wed, 2 Aug 2000 10:46:09 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: [9fans] 'date' question Reply-to: ngr@9fs.org Message-ID: <3987FBF1.3541.22BEB1D4@localhost> In-reply-to: <200008020908.FAA17198@cse.psu.edu> X-mailer: Pegasus Mail for Win32 (v3.12c) X-Received: By mailgate.Cadence.COM as CAA04460 at Wed Aug 2 02:42:39 2000 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu If you have a fileserver, don't forget to fix that too. The console displays local time. The timezone is hardwired to the east coast. You can either adjust the local time to compensate, or change the source. The former will work, but dumps then run at 10am in the morning which can be a bit irritating. > you might need to eliminate the use of the -L option to timesync(8) > by termrc or cpurc if your hardware clock is GMT. > > From owner-9fans@cse.psu.edu Wed Aug 2 05:46:38 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA18377 for 9fans-outgoing; Wed, 2 Aug 2000 05:46:38 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from vivido.hci-net ([212.240.227.6]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id FAA18370 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 05:46:31 -0400 (EDT) From: forsyth@vitanuova.com Message-Id: <200008020946.FAA18370@cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Installing the updates Date: Wed, 2 Aug 2000 10:47:19 0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-ikoqqkdgqrhiosdedhlexhaoct" Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu This is a multi-part message in MIME format. --upas-ikoqqkdgqrhiosdedhlexhaoct Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit >>We already know that it is non-trivial to port much >>non-Plan9 code to Plan9-native and vice versa. i have found porting well written Unix code to native plan 9 (libc.h, 8[cl] etc) to be straightforward. the main exceptions are socket calls but since those involve deleting lots of ugly lines of code, it's satisfying, and since they mainly involve call setup with the I/O the same read/write after that, it's not too hard. the compilers sometimes pick up old problems that were lurking though. --upas-ikoqqkdgqrhiosdedhlexhaoct Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from punt-1.mail.demon.net by mailstore for forsyth@vitanuova.com id 965208129:10:25149:26; Wed, 02 Aug 2000 09:22:09 GMT Received: from claven.cse.psu.edu ([130.203.3.50]) by punt-1.mail.demon.net id aa1101070; 2 Aug 2000 9:22 GMT Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) with SMTP id FAA17738; Wed, 2 Aug 2000 05:21:52 -0400 (EDT) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Wed, 2 Aug 2000 05:21:34 -0400 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA17678 for 9fans-outgoing; Wed, 2 Aug 2000 05:21:23 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id FAA17671 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 05:21:16 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13JuZs-0007lX-00 for 9fans@cse.psu.edu; Wed, 02 Aug 2000 10:12:40 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: cse.psu.edu!9fans Date: Wed, 2 Aug 2000 09:11:37 GMT Message-ID: <3987E345.4B8F3643@home.com> Organization: @Home Network Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200007311515.LAA18248@cse.psu.edu>, <014501bffbb1$bef147d0$62356887@HWTPC> Reply-To: null.net!DAGwyn Subject: Re: [9fans] Installing the updates Sender: cse.psu.edu!owner-9fans Reply-To: cse.psu.edu!9fans Precedence: bulk > The APE headers do indeed conform. Okay, problem solved. The Plan9 native headers can certainly do whatever Rob and crew think is best. We already know that it is non-trivial to port much non-Plan9 code to Plan9-native and vice versa. --upas-ikoqqkdgqrhiosdedhlexhaoct-- From owner-9fans@cse.psu.edu Wed Aug 2 05:51:26 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA18593 for 9fans-outgoing; Wed, 2 Aug 2000 05:51:26 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id FAA18584 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 05:51:15 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13Jv3v-0000dJ-00 for 9fans@cse.psu.edu; Wed, 02 Aug 2000 10:43:43 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Wed, 2 Aug 2000 09:39:25 GMT From: "Douglas A. Gwyn" Message-ID: <3987E548.683EC5A4@home.com> Organization: @Home Network Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200008011256.IAA15699@cse.psu.edu> Reply-To: DAGwyn@null.net Subject: Re: [9fans] Installing the updates Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu rob pike wrote: > Plan 9 is non-standard and proud of it. That's fine; research involves trying out different ideas. If and when it makes importing code a big enough problem, then it could be changed (without adversely impacting on existing code). From owner-9fans@cse.psu.edu Wed Aug 2 05:51:38 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA18615 for 9fans-outgoing; Wed, 2 Aug 2000 05:51:38 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id FAA18592 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 05:51:25 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13Jv3v-0000dB-00 for 9fans@cse.psu.edu; Wed, 02 Aug 2000 10:43:43 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Wed, 2 Aug 2000 09:39:05 GMT From: "Douglas A. Gwyn" Message-ID: <3987E4B0.FEA6B593@home.com> Organization: @Home Network Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <8m6dhf$74d$1@inputplus.demon.co.uk>, <200008011603.MAA05857@egyptian-gods.MIT.EDU> Reply-To: DAGwyn@null.net Subject: Re: [9fans] Installing the updates Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Greg Hudson wrote: > a low cost (and one which can be optimized away for ifdef-protected > headers; I'm told gcc does so). The general trick is for the preprocessor to maintain a table of (lock_symbol,header_name) entries, and when a new header file is read, to make a note whether it consists of #ifndef symbol...#endif (after comment processing). If so, the symbol and file name go into the table. #include processing always checks the table and if there is an entry for the file, if the associated lock_symbol is defined, the file is not even opened. This trick does no harm. From owner-9fans@cse.psu.edu Wed Aug 2 06:02:24 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id GAA19029 for 9fans-outgoing; Wed, 2 Aug 2000 06:02:24 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id GAA19025 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 06:02:18 -0400 (EDT) Received: (qmail 7534151 invoked from network); 2 Aug 2000 10:02:17 -0000 Received: from r198m3.cybercable.tm.fr (HELO coma) ([195.132.198.3]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for <9fans@cse.psu.edu>; 2 Aug 2000 10:02:17 -0000 Message-ID: <01c301bffc67$52a2df60$03c684c3@psychobasketcase.org> Reply-To: "Boyd Roberts" From: "Boyd Roberts" To: <9fans@cse.psu.edu> References: <200008020946.FAA18370@cse.psu.edu> Subject: Re: [9fans] Installing the updates Date: Wed, 2 Aug 2000 11:52:08 +0200 Organization: Psycho Basket Case Outpatients Cllinic MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu From: > > i have found porting well written Unix > code to native plan 9 (libc.h, 8[cl] etc) so have i. in two days with sam i very roughly ported my MH like user agent. of, course i cheated with the odd hack define. the worst part was getting the mailbox locking right and those damn morF's! From owner-9fans@cse.psu.edu Wed Aug 2 06:06:26 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id GAA19220 for 9fans-outgoing; Wed, 2 Aug 2000 06:06:25 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id GAA19215 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 06:06:19 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13JvHo-0001Hf-00 for 9fans@cse.psu.edu; Wed, 02 Aug 2000 10:58:04 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Wed, 2 Aug 2000 09:53:55 GMT From: "Douglas A. Gwyn" Message-ID: <3987ED0B.CFFF496C@home.com> Organization: @Home Network Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200008011335.JAA17292@cse.psu.edu> Reply-To: DAGwyn@null.net Subject: Re: [9fans] Installing the updates Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu rob pike wrote: > To meet that goal, we had to break with the ANSI include rules. I don't see why. The C standard does *not* say that you *must* include any header multiple times; you can enforce Plan9 programming discipline regardless of whether headers have internal idempotency locks. The presence or absence of such locks has no effect on Plan9-style applications that #include every header needed, once apiece in whatever the proper order is. Indeed, the Plan9 header discipline imposes an interdepency ordering upon the system headers, such that e.g. and cannot both define something that the other header needs, which might otherwise be a natural thing to do. It is nice that Plan9 programs don't individually use #ifdefs and config, but really the use of centrally-defined types and macros in a common environment avoids such stuff. In effect, the differences are factored out to a global level. The reason for remaining #ifdefs in many actual applications is that they have to work in many environments that differ in much more radical ways than any two instances of Plan9. There are ways of factoring out the differences, and I generally recommend them in the design phase, but most applications are created by people who don't know (or care) about all the ways other environments differ from the one where they do their development, and some other poor sap later on is stuck with porting their code. Repackaging the whole thing might not be feasible, so patching places where problems crop up using #ifdefs is expedient. (More work for the *next* poor sap.) It would be nice if everybody had the experience and foresight to design his code properly in the first place, with all system dependencies isolated modularly, but in the real world that seldom seems to happen. From owner-9fans@cse.psu.edu Wed Aug 2 07:06:23 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id HAA19997 for 9fans-outgoing; Wed, 2 Aug 2000 07:06:23 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id HAA19993 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 07:06:17 -0400 (EDT) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13JwBL-0003oG-00 for 9fans@cse.psu.edu; Wed, 02 Aug 2000 11:55:27 +0100 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Wed, 2 Aug 2000 10:53:57 GMT From: Ralph Corderoy Message-ID: <8m8uev$5nf$1@inputplus.demon.co.uk> Organization: InputPlus Ltd. References: <200008011627.MAA23591@cse.psu.edu> Subject: Re: [9fans] Installing the updates Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Hi, > Yup. That little note, written for a CS class in 1987, has been > expanded into a book, published last year, called The Practice of > Programming. For those that haven't already bought and read it see http://cm.bell-labs.com/cm/cs/tpop/index.html and then go and buy and read it. Ralph. From owner-9fans@cse.psu.edu Wed Aug 2 09:20:30 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id JAA22296 for 9fans-outgoing; Wed, 2 Aug 2000 09:20:30 -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 JAA22272 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 09:20:06 -0400 (EDT) From: presotto@plan9.bell-labs.com Message-Id: <200008021320.JAA22272@cse.psu.edu> Date: Wed, 2 Aug 2000 09:20:00 -0400 To: miller@hamnavoe.demon.co.uk, 9fans@cse.psu.edu Subject: Re: [9fans] Kernel question: i386 test-and-set problem MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-pqpuzybbzqmndsrodfcnacjtmq" Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu This is a multi-part message in MIME format. --upas-pqpuzybbzqmndsrodfcnacjtmq Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit If it were at all possible for wakeup to be called with r already freed, the code would be wrong to begin with since r is an argument to wakeup. Sleep and wakeup have to be syncronized somewhat in the first place just to work. Wakeup inherenly has to expect that the sleep won't free r before it's called. Since the sleep and wakeup are called by code that knows about the structures the Rendezvous is kept in, they can do this. For example, if we're descending a list that contains rendezvous structures and the list operations are made atomic, the structure won't be in the list if the returning sleep freed it and the wakeup won't find it. However, that is not true of postnote which is coming out of left field and doesn't have any knowledge of the deep structure of the process it is noting. It can take into account no invariants implicit in the process itself. --upas-pqpuzybbzqmndsrodfcnacjtmq Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Wed Aug 2 05:13:07 EDT 2000 Received: from cse.psu.edu ([130.203.3.50]) by plan9; Wed Aug 2 05:13:06 EDT 2000 Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) with SMTP id EAA16632; Wed, 2 Aug 2000 04:58:18 -0400 (EDT) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Wed, 2 Aug 2000 04:58:02 -0400 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA16586 for 9fans-outgoing; Wed, 2 Aug 2000 04:57:56 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id EAA16580 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 04:57:49 -0400 (EDT) From: miller@hamnavoe.demon.co.uk Received: from hamnavoe.demon.co.uk ([158.152.225.204] helo=hamnavoe) by anchor-post-31.mail.demon.net with smtp (Exim 2.12 #1) id 13JuLT-0005k5-0V for 9fans@cse.psu.edu; Wed, 2 Aug 2000 09:57:48 +0100 To: 9fans@cse.psu.edu Subject: Re: [9fans] Kernel question: i386 test-and-set problem Date: Wed, 2 Aug 2000 09:32:59 0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk > We did try your solution since it was the obious one. Wasn't obvious to me. It emerged from an attempt to sketch a correctness proof and then derive a version of the algorithm which would correspond to it. > Process p now continues after the sleep: > > process p: > sleep(r); > free(r) > > Process y now does > > xxx = malloc(234); > xxx->a = 12; > > And finally process x does its lock(r). We've just > clobbered some other processes kernel structure. Ah. It had not actually occurred to me that a kernel process might be freeing a data structure while another process still held a pointer into it. How naive of me. If the scenario above is really allowed, I don't see why it isn't just as much a problem with the existing kernel. Even without the interference of postnote(), we might have sleep(r) finding the wakeup condition true and returning immediately, so that the free(r) and malloc() could happen while or even before wakeup(r) runs. So when /sys/src/9/port/proc.c:#10217,#10286 is executed, r points to something which is no longer a Rendez structure. Therefore r->p could be anything, and the lock(&p->rlock) could clobber something or even cause a memory fault. Or am I missing something obvious again? -- Richard --upas-pqpuzybbzqmndsrodfcnacjtmq-- From owner-9fans@cse.psu.edu Wed Aug 2 09:23:37 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id JAA22571 for 9fans-outgoing; Wed, 2 Aug 2000 09:23:37 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from priv-edtnes12-hme0.telusplanet.net (fepout4.telus.net [199.185.220.239] (may be forged)) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id JAA22567 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 09:23:31 -0400 (EDT) Received: from djhender1 ([161.184.64.43]) by priv-edtnes12-hme0.telusplanet.net (InterMail vM.4.01.02.11 201-229-116-111) with SMTP id <20000802132300.BFPR1814.priv-edtnes12-hme0.telusplanet.net@djhender1> for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 07:23:00 -0600 Message-ID: <007001bffc84$d5efac00$0500a8c0@telusplanet.net> From: "Doug Henderson" To: <9fans@cse.psu.edu> Subject: [9fans] ugrading edition 2 graphics to edition 3 Date: Wed, 2 Aug 2000 07:23:20 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu While I looked at Plan9 a number of years back - I downloaded the 3 disk install set I think, I didn't get seriously involved until 3rd edition, what with ADSL & cable making 50Meg downloads a practicality for the individual. A lot of the existing native plan9 source code out there is written for the 2nd edition graphics libraries, with headers like , , and . I don't have access to the 2nd edition graphics library documention. I have not seen both versions of any programs which have been transformed from 2nd to 3rd editions. One of the most valuable aids (for me) to learning a new environment is building and experimenting with existing code. So I am lacking some of the tools that I can use to figure out how to do these tranforms. Is the 2nd edition documentation still available anywhere, for download or browsing? Is there a porting guide? A feature comparision? The looks like it used to be supported in the APE environment (the header is still there in 3rd, but it doesn't work - also no libg.a). Is the 3rd edition and etc. going to be supported under the 3rd edition? Anyone working on that? Are there guidelines / suggestions for doing such a thing? My efforts so far get to the linker where I get a conflict between the ape atexit and the libc atexit (I think). Are there any feature test programs available? I mean simple programs (perhaps used by the developers of the 3rd edition graphics libraries) to excercise the features of the code. I find these kinds of programs a valuable starting point for testing out my own pieces of code - the ones where I find out how to do the basic things I need for a larger project. From owner-9fans@cse.psu.edu Wed Aug 2 10:45:56 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id KAA24719 for 9fans-outgoing; Wed, 2 Aug 2000 10:45:56 -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 KAA24715 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 10:45:52 -0400 (EDT) Message-Id: <200008021445.KAA24715@cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] ugrading edition 2 graphics to edition 3 From: "rob pike" Date: Wed, 2 Aug 2000 10:45:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > The looks like it used to be supported in the APE environment (the > header is still there in 3rd, but it doesn't work - also no libg.a). APE has been a bit neglected the last year or two. There should certainly be an APE version of . I removed here; it was a dreg. Thanks for catching it. > One of the most valuable aids (for me) to learning a new environment is > building and experimenting with existing code. So I am lacking some of the > tools that I can use to figure out how to do these tranforms. Is the 2nd > edition documentation still available anywhere, for download or browsing? Is > there a porting guide? A feature comparision? None of the above, really. I suppose we could put the old documentation on line - in fact it's still there, just hidden - but is that actually useful? Is there much 2nd edition stuff you feel needs to be updated? -rob From owner-9fans@cse.psu.edu Wed Aug 2 10:48:32 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id KAA24915 for 9fans-outgoing; Wed, 2 Aug 2000 10:48:31 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id KAA24902 for <9fans@cse.psu.edu>; Wed, 2 Aug 2000 10:48:22 -0400 (EDT) From: miller@hamnavoe.demon.co.uk Received: from hamnavoe.demon.co.uk ([158.152.225.204] helo=hamnavoe) by finch-post-10.mail.demon.net with smtp (Exim 2.12 #1) id 13Jzoi-000AkU-0A for 9fans@cse.psu.edu; Wed, 2 Aug 2000 14:48:20 +0000 To: 9fans@cse.psu.edu Subject: Re: [9fans] Kernel question: i386 test-and-set problem Date: Wed, 2 Aug 2000 15:51:33 0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > If it were at all possible for wakeup to be called with > r already freed, the code would be wrong to begin with > since r is an argument to wakeup. For things to go wrong it's not necessary for wakeup to be called after r is freed; what I said was "the free(r) and malloc() could happen *while* or even before wakeup(r) runs". It's sufficient to have sleep(r) and wakeup(r) racing on two processors. We could have this interleaving of events: sleep(r) is called wakeup(r) is called sleep tests wakeup condition, returns wakeup is delayed by an interrupt on its processor caller of sleep deallocates structure containing r some other process reallocates r and clobbers r->p wakeup resumes, dereferences r->p, ka-boom! If you think sleep and wakeup are sufficiently interlocked by higher level considerations that this can't happen, then let's use your scenario with postnote, mutatis mutandis to apply to the existing kernel algorithm: process x calls postnote: postnote(p): p->notepending = 1 lock(p->rlock) r = p->r if r != 0 if(r->p == p && p->r == r) r->p = 0 p->r = 0 ready(p) unlock(p->rlock) Immediately after the unlock(p->rlock) is executed, process q calls wakeup process q: wakeup(r): {wakeup condition is satisfied} coherence() p = r->p if p != 0 lock(p->rlock) if (r->p == p && p->r == r) r->p = 0 p->r = 0 ready(p) unlock(p->rlock)