From owner-9fans@cse.psu.edu Tue Mar 7 11:19:33 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id LAA20205 for 9fans-outgoing; Tue, 7 Mar 2000 11:19:32 -0500 (EST) 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 LAA20201 for <9fans@cse.psu.edu>; Tue, 7 Mar 2000 11:19:12 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12SMb5-0005ek-00 for 9fans@cse.psu.edu; Tue, 07 Mar 2000 16:12:35 +0000 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, 7 Mar 2000 09:32:30 GMT From: David Butler Message-ID: <8a20ct$d90@library1.airnews.net> Organization: Airnews.net! at Internet America References: , <89fko7$sh9@library2.airnews.net>, Subject: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Roman Shaposhnick wrote in message news:slrn8c7lt4.c7k.vugluskr@unicorn.math.spbu.ru... > On Tue, 29 Feb 2000 09:29:38 GMT, David Butler wrote: > >Roman Shaposhnick wrote in message > >news:slrn8bfrif.u5c.vugluskr@unicorn.math.spbu.ru... > To be more precise there are several things that can not stop bothering me: > > 1. I still consider the Tclone/Topen/Tread/Tclunk a bit lengthy, and > still can not understand limitations of why we can not walk opened > fids. If Twalk was allowed on an open fid, (assuming it is a directory, because if it is a file it doesn't make any sense) does that mean you are done reading the directory? If you are, you should release the resources keeping track of the open context, so you still need a Tclunk. Perhaps you would need a new clunk that says "leave the fid pointing to the directory, so I can walk it". That would be like a clunk/walk. Instead of doing that, why don't you simply have a Tclunk and a Tclwalk? In other words, the result is the same. The real reason for the "lengthy" conversation is the Tclone/Twalk part. That is part of the price that is paid to remove the '/' as a directory separator, which IMHO is a good thing. > 2. Why directories have a conventional length of 0? IMHO, it is very > annoying, since the only way to know the exact number of > directory entries is to read it up to the end. There is more to the issue than just the 0, though. Directories in Plan9 have no "holes" (according to the protocol) and can NOT be seek(2)ed into. In other words, you can ONLY sequentially read a directory. The theory breaks down real fast when you read a directory that concurrently has creates and removes occuring. I've seen ls(1) both list file names twice and not show files that actually exist! What is more interesting is that the behavior is different between file servers implemented in the cpu/terminal kernel vs kfs or "the file server". In my system I've made them consistent and fixed the dup/missing names by making directories seekable (to a point. seek(fd, n, 2) == seek(fd, n, 0) because the length of a directory is still 0, as it should be). > available info would be enough for me. By the way, why htmled man pages > have a lot of HTML errors ? If this is a bug, then may be somewhere there > is a site with P9 htmled man pages that I can read, not decode ? Since Plan9 is copyrighted and there are no other distributors of the system commercially, the manuals can only be seen on bell-labs site from the web. I don't see any formating issues with section 5 of the manual (where 9P is documented) so I don't know why you would have a problem. Perhaps you could give a URL of a problem page? From owner-9fans@cse.psu.edu Tue Mar 7 11:20:39 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id LAA20265 for 9fans-outgoing; Tue, 7 Mar 2000 11:20:39 -0500 (EST) 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 LAA20253 for <9fans@cse.psu.edu>; Tue, 7 Mar 2000 11:20:19 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12SMaV-0005eS-00 for 9fans@cse.psu.edu; Tue, 07 Mar 2000 16:11:59 +0000 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, 7 Mar 2000 09:32:30 GMT From: David Butler Message-ID: <8a20ct$d90@library1.airnews.net> Organization: Airnews.net! at Internet America References: , <89fko7$sh9@library2.airnews.net>, Subject: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Roman Shaposhnick wrote in message news:slrn8c7lt4.c7k.vugluskr@unicorn.math.spbu.ru... > On Tue, 29 Feb 2000 09:29:38 GMT, David Butler wrote: > >Roman Shaposhnick wrote in message > >news:slrn8bfrif.u5c.vugluskr@unicorn.math.spbu.ru... > To be more precise there are several things that can not stop bothering me: > > 1. I still consider the Tclone/Topen/Tread/Tclunk a bit lengthy, and > still can not understand limitations of why we can not walk opened > fids. If Twalk was allowed on an open fid, (assuming it is a directory, because if it is a file it doesn't make any sense) does that mean you are done reading the directory? If you are, you should release the resources keeping track of the open context, so you still need a Tclunk. Perhaps you would need a new clunk that says "leave the fid pointing to the directory, so I can walk it". That would be like a clunk/walk. Instead of doing that, why don't you simply have a Tclunk and a Tclwalk? In other words, the result is the same. The real reason for the "lengthy" conversation is the Tclone/Twalk part. That is part of the price that is paid to remove the '/' as a directory separator, which IMHO is a good thing. > 2. Why directories have a conventional length of 0? IMHO, it is very > annoying, since the only way to know the exact number of > directory entries is to read it up to the end. There is more to the issue than just the 0, though. Directories in Plan9 have no "holes" (according to the protocol) and can NOT be seek(2)ed into. In other words, you can ONLY sequentially read a directory. The theory breaks down real fast when you read a directory that concurrently has creates and removes occuring. I've seen ls(1) both list file names twice and not show files that actually exist! What is more interesting is that the behavior is different between file servers implemented in the cpu/terminal kernel vs kfs or "the file server". In my system I've made them consistent and fixed the dup/missing names by making directories seekable (to a point. seek(fd, n, 2) == seek(fd, n, 0) because the length of a directory is still 0, as it should be). > available info would be enough for me. By the way, why htmled man pages > have a lot of HTML errors ? If this is a bug, then may be somewhere there > is a site with P9 htmled man pages that I can read, not decode ? Since Plan9 is copyrighted and there are no other distributors of the system commercially, the manuals can only be seen on bell-labs site from the web. I don't see any formating issues with section 5 of the manual (where 9P is documented) so I don't know why you would have a problem. Perhaps you could give a URL of a problem page? From owner-9fans@cse.psu.edu Thu Mar 9 04:35:40 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA20840 for 9fans-outgoing; Thu, 9 Mar 2000 04:35:40 -0500 (EST) 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 EAA20836 for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 04:35:34 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12SzFP-0000jn-00 for 9fans@cse.psu.edu; Thu, 09 Mar 2000 09:28:47 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Thu, 9 Mar 2000 09:26:21 GMT From: Roman Shaposhnick Message-ID: Organization: St.Petersburg University References: <89fko7$sh9@library2.airnews.net>, , <8a20ct$d90@library1.airnews.net> Subject: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu On Tue, Mar 07, 2000 at 09:32:30AM +0000, David Butler wrote: > Roman Shaposhnick wrote in message > news:slrn8c7lt4.c7k.vugluskr@unicorn.math.spbu.ru... > > On Tue, 29 Feb 2000 09:29:38 GMT, David Butler wrote: > > >Roman Shaposhnick wrote in message > > >news:slrn8bfrif.u5c.vugluskr@unicorn.math.spbu.ru... > > > To be more precise there are several things that can not stop bothering > me: > > > > 1. I still consider the Tclone/Topen/Tread/Tclunk a bit lengthy, and > > still can not understand limitations of why we can not walk opened > > fids. > > If Twalk was allowed on an open fid, (assuming it is a directory, > because if it is a file it doesn't make any sense) does that mean > you are done reading the directory? No this is not always true since I could be interested in some particular property of each file in the directory. That's why I wonder why I should read the whole directory or clone fids pointing to it but not being opened, when I can just issue Twalk message. > If you are, you should release > the resources keeping track of the open context, so you still need a > Tclunk. Perhaps you would need a new clunk that says "leave the > fid pointing to the directory, so I can walk it". Let me put it this way: I suspect that there is a good reason why I can not Twalk into open directory ( though there was no clean explanation yet ) but I definitely can not understand why openness is persistent property in the sense that when I clone the open fid the copy happens to be open too. > That would be like > a clunk/walk. Instead of doing that, why don't you simply have a > Tclunk and a Tclwalk? In other words, the result is the same. I understand. Moreover, I have elaborated workaround ( or may be the only one correct solution ) that is exactly what are you talking of. But I still can not understand the roots of this extra limitations. Why ? Why are they there -- that's my only question. > The real reason for the "lengthy" conversation is the Tclone/Twalk > part. That is part of the price that is paid to remove the '/' as a > directory separator, which IMHO is a good thing. That's right. And that's the thing that I understand quite well. I can say, that this is the one of the features that makes 9P very nice and powerful and forces one to "think different" (tm) :). That's like Lisp. You can not think the old pascal-c-fortran-algol way when you use it. Very refreshing and enjoyable feeling. > > 2. Why directories have a conventional length of 0? IMHO, it is very > > annoying, since the only way to know the exact number of > > directory entries is to read it up to the end. > > There is more to the issue than just the 0, though. Directories in > Plan9 have no "holes" (according to the protocol) and can NOT > be seek(2)ed into. Hmm. That sounds strange. As stated in read(2) I could read from any offset any number of bytes with the only one restriction: "The read request message must have offset and count zero modulo DIRLEN". Are you talking about seek(2) beyond the "end" of directory ? > In other words, you can ONLY sequentially read a directory. I guess not, or may be I can not get what are you talking about. > The theory breaks down real fast when you read > a directory that concurrently has creates and removes occurring. > I've seen ls(1) both list file names twice and not show files that > actually exist! Hmm. It depends of how do you think of this :). I guess that ls(1) lists the exact contents of the directory, or, being more precise, the partial snapshot taken at that particular moment. But nevertheless, this is just the same behavior that you can see with a set of concurrent readers and writers of the plain file with one exception that you can not lock directory. Or can you ? > What is more interesting is that the behavior is > different between file servers implemented in the cpu/terminal > kernel vs kfs or "the file server". In my system I've made them > consistent and fixed the dup/missing names by making directories > seekable (to a point. seek(fd, n, 2) == seek(fd, n, 0) because the > length of a directory is still 0, as it should be). Why ? Why it should be 0. Because the length can change after Tstat ? Well, that's ok. That's just the situation with a plain file. Moreover, I can always issue as many Tstat as I would like. What wrong with letting length represent the number of directory entries ? > > available info would be enough for me. By the way, why htmled man pages > > have a lot of HTML errors ? If this is a bug, then may be somewhere there > > is a site with P9 htmled man pages that I can read, not decode ? > > Since Plan9 is copyrighted and there are no other distributors of the > system commercially, the manuals can only be seen on bell-labs site > from the web. Oh-no. Bad news. > I don't see any formating issues with section 5 of the > manual (where 9P is documented) so I don't know why you would > have a problem. Perhaps you could give a URL of a problem page? Sure. Here it is: http://inferno.bell-labs.com/magic/man2html/6/auth. There are a lot of strange things like: delim $$ define lbr ' roman "{" ' define rbr ' roman "}" ' or $CH sub c$ which should be "CH c", I guess. Thanks, Roman. From owner-9fans@cse.psu.edu Thu Mar 9 05:26:05 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA21428 for 9fans-outgoing; Thu, 9 Mar 2000 05:26:05 -0500 (EST) 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 FAA21424 for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 05:26:00 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12Szny-0001CJ-00 for 9fans@cse.psu.edu; Thu, 09 Mar 2000 10:04:30 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Thu, 9 Mar 2000 10:02:05 GMT From: "Douglas A. Gwyn" Message-ID: <38C7751F.E4FD3F95@null.net> Organization: @Home Network Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: , <8a20ct$d90@library1.airnews.net>, Subject: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Roman Shaposhnick wrote: > There are a lot of strange things like: > delim $$ define lbr ' roman "{" ' define rbr ' roman "}" ' > or > $CH sub c$ > which should be "CH c", I guess. Yes, those are "eqn" constructs, presumably not processed into HTML because HTML lacks a good equation sublanguage. From owner-9fans@cse.psu.edu Thu Mar 9 05:51:25 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA21765 for 9fans-outgoing; Thu, 9 Mar 2000 05:51:25 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from caldo.demon.co.uk (caldo.demon.co.uk [194.222.207.148]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id FAA21761 for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 05:51:17 -0500 (EST) From: forsyth@caldo.demon.co.uk Message-Id: <200003091051.FAA21761@cse.psu.edu> To: 9fans@cse.psu.edu Date: Thu, 9 Mar 2000 10:50:00 GMT Subject: Re: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu >>I can always issue as many Tstat as I would like. What wrong with >>letting length represent the number of directory entries ? many interesting directories are generated on-the-fly (indeed that's the normal case for devices). any size that could be given for any directory is at best a hint, and it is hard to see how to put it to any essential use. consequently, having to run through the generation code just to produce a less-than-useful size seems a bit of a waste of time. i made the extra effort in an operating system of my own, but i didn't find it especially worthwhile. it's worth noting that there are plenty of files in Plan 9 that can be read but have length set to zero (for much the same reason). the conventions are not completely consistent in practice, possibly caused by differing authors or changing priorities: compare {ls -l /dev/time} and {ls -l '#r/rtc'}. From owner-9fans@cse.psu.edu Thu Mar 9 08:18:34 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id IAA23354 for 9fans-outgoing; Thu, 9 Mar 2000 08:18:33 -0500 (EST) 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 IAA23349 for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 08:18:29 -0500 (EST) From: presotto@plan9.bell-labs.com Message-Id: <200003091318.IAA23349@cse.psu.edu> Date: Thu, 9 Mar 2000 08:18:23 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: 9p question 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 Mea culpa, mea culpa, mea maxima culpa. My troff to html program doesn't do eqn. Guess I'ld better eqn the pages before running em through. Thanks for Roman for noticing. From owner-9fans@cse.psu.edu Thu Mar 9 08:50:52 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id IAA23924 for 9fans-outgoing; Thu, 9 Mar 2000 08:50:52 -0500 (EST) 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 IAA23914 for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 08:50:45 -0500 (EST) Message-Id: <200003091350.IAA23914@cse.psu.edu> From: "rob pike" Subject: Re: [9fans] Re: 9p question Date: Thu, 9 Mar 2000 08:50:41 -0500 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 > The real reason for the "lengthy" conversation is the Tclone/Twalk > part. That is part of the price that is paid to remove the '/' as a > directory separator No. The real reason is that after each walk the client must check whether the point-so-far is in the mount table. That's why it's done a path element at a time, and why it's so slow. Other designs have been proposed that would allow a walk message to contain multiple elements (requiring the server to parse and understand '/'), but it's such a pain to change the protocol. Seeking on a directory is forbidden because it's hard enough to implement reading a union directory without seek. The internal structure that must be maintained in the kernel was deemed too hard to maintain other than by sequential access, so we made seeking on a directory illegal. It didn't seem worth the implementation overhad. I still feel that way. >There are a lot of strange things like: > delim $$ define lbr ' roman "{" ' define rbr ' roman "}" ' >or > $CH sub c$ >which should be "CH c", I guess. Would you have noticed this if it didn't contain your name? -rob From owner-9fans@cse.psu.edu Thu Mar 9 09:49:33 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id JAA25277 for 9fans-outgoing; Thu, 9 Mar 2000 09:49:33 -0500 (EST) 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 JAA25272 for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 09:49:27 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12T42H-0001GS-00 for 9fans@cse.psu.edu; Thu, 09 Mar 2000 14:35:33 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Thu, 9 Mar 2000 14:21:17 GMT From: Roman Shaposhnick Message-ID: Organization: St.Petersburg University References: <200003091318.IAA23349@cse.psu.edu> Subject: Re: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu On Thu, 9 Mar 2000 13:36:51 GMT, presotto@plan9.bell-labs.com wrote: >Mea culpa, mea culpa, mea maxima culpa. My troff to html program doesn't >do eqn. Guess I'ld better eqn the pages before running em through. >Thanks for Roman for noticing. Dave, and may be there is a chance to get troff sources ? Or this is restricted by policy ? Thanks, Roman. From owner-9fans@cse.psu.edu Thu Mar 9 10:11:20 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id KAA25823 for 9fans-outgoing; Thu, 9 Mar 2000 10:11:20 -0500 (EST) 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 KAA25818 for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 10:11:14 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12T4Ix-0001WJ-00 for 9fans@cse.psu.edu; Thu, 09 Mar 2000 14:52:47 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Thu, 9 Mar 2000 14:44:35 GMT From: Roman Shaposhnick Message-ID: Organization: St.Petersburg University References: <200003091051.FAA21761@cse.psu.edu> Subject: Re: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu On Thu, 9 Mar 2000 11:12:43 GMT, forsyth@caldo.demon.co.uk wrote: >>>I can always issue as many Tstat as I would like. What wrong with >>>letting length represent the number of directory entries ? > >many interesting directories are generated on-the-fly (indeed that's the >normal case for devices). any size that could be >given for any directory is at best a hint, and it is hard to see how to put >it to any essential use. Just like with normal or, well, quasi-normal files. There is no any doubt that this can be done just the same way. Or can not ? >consequently, having to run through the generation >code just to produce a less-than-useful size seems a bit of a waste >of time. Yes, I understand your point, but my question was why the behavior is inconsistent? I do not believe that for most files served by the file server the size is zero, just because it seems to be so easy and natural to fill the proper field with the file size when it is known and to put there a special value when it is not. >i made the extra effort in an operating system of my own, >but i didn't find it especially worthwhile. It is not, especially when it is an exception, not the rule. IMHO, as always. >it's worth noting that there are plenty of files in Plan 9 that can be read >but have length set to zero (for much the same reason). >the conventions are not completely consistent in practice, >possibly caused by differing authors or changing >priorities: compare {ls -l /dev/time} and {ls -l '#r/rtc'}. May be that's the answer. Different attitudes. I think this can explain a lot. But I hope that there is a different answer. Will wait. :) Roman. From owner-9fans@cse.psu.edu Thu Mar 9 10:33:15 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id KAA26376 for 9fans-outgoing; Thu, 9 Mar 2000 10:33:15 -0500 (EST) 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 KAA26371 for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 10:33:10 -0500 (EST) From: presotto@plan9.bell-labs.com Message-Id: <200003091533.KAA26371@cse.psu.edu> Date: Thu, 9 Mar 2000 10:33:05 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: 9p question MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-cujudtopreocybipeuixodzphu" Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu This is a multi-part message in MIME format. --upas-cujudtopreocybipeuixodzphu Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I'll put a tar out ther. --upas-cujudtopreocybipeuixodzphu Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu Mar 9 10:03:46 EST 2000 Received: from cse.psu.edu ([130.203.3.50]) by plan9; Thu Mar 9 10:03:46 EST 2000 Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) with SMTP id JAA25319; Thu, 9 Mar 2000 09:49:49 -0500 (EST) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Thu, 9 Mar 2000 09:49:38 -0500 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id JAA25277 for 9fans-outgoing; Thu, 9 Mar 2000 09:49:33 -0500 (EST) 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 JAA25272 for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 09:49:27 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12T42H-0001GS-00 for 9fans@cse.psu.edu; Thu, 09 Mar 2000 14:35:33 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Thu, 9 Mar 2000 14:21:17 GMT From: Roman Shaposhnick Message-ID: Organization: St.Petersburg University References: <200003091318.IAA23349@cse.psu.edu> Subject: Re: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk On Thu, 9 Mar 2000 13:36:51 GMT, presotto@plan9.bell-labs.com wrote: >Mea culpa, mea culpa, mea maxima culpa. My troff to html program doesn't >do eqn. Guess I'ld better eqn the pages before running em through. >Thanks for Roman for noticing. Dave, and may be there is a chance to get troff sources ? Or this is restricted by policy ? Thanks, Roman. --upas-cujudtopreocybipeuixodzphu-- From owner-9fans@cse.psu.edu Thu Mar 9 13:11:04 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id NAA29811 for 9fans-outgoing; Thu, 9 Mar 2000 13:11:03 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from unicorn.math.spbu.ru (vugluskr@unicorn.math.spbu.ru [195.19.226.6]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id NAA29805 for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 13:10:54 -0500 (EST) Received: (from vugluskr@localhost) by unicorn.math.spbu.ru (8.9.3/8.9.3) id VAA11193; Thu, 9 Mar 2000 21:10:49 +0300 Date: Thu, 9 Mar 2000 21:10:49 +0300 From: "Roman V. Shaposhnick" To: 9fans@cse.psu.edu Cc: presotto@plan9.bell-labs.com Subject: Re: [9fans] Re: 9p question Message-ID: <20000309211049.A11179@unicorn.math.spbu.ru> References: <200003091533.KAA26371@cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <200003091533.KAA26371@cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu On Thu, Mar 09, 2000 at 10:33:05AM -0500, presotto@plan9.bell-labs.com wrote: > I'll put a tar out ther. Please let me know the exact location. I'm very eager to get the well formated page for auth(6). Thanks, Roman. From owner-9fans@cse.psu.edu Thu Mar 9 13:34:28 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id NAA00386 for 9fans-outgoing; Thu, 9 Mar 2000 13:34:28 -0500 (EST) 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 NAA00381 for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 13:34:21 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12T7f5-0004Wi-00 for 9fans@cse.psu.edu; Thu, 09 Mar 2000 18:27:51 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Thu, 9 Mar 2000 18:05:22 GMT From: Roman Shaposhnick Message-ID: Organization: St.Petersburg University References: <200003091350.IAA23914@cse.psu.edu> Subject: Re: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu On Thu, 9 Mar 2000 14:08:23 GMT, rob pike wrote: >> The real reason for the "lengthy" conversation is the Tclone/Twalk >> part. That is part of the price that is paid to remove the '/' as a >> directory separator > >No. The real reason is that after each walk the client must check whether >the point-so-far is in the mount table. That's why it's done a path >element at a time, and why it's so slow. Other designs have been >proposed that would allow a walk message to contain multiple >elements (requiring the server to parse and understand '/'), I think this would be a very bad thing. From my point of view the main strength of 9P is the fact that it allows one to manipulate a hierarchy without bothering how names of the members are encoded. That's like you have a partial ordered set and define elements via their relationship between each other. I think this gives a maximum level of freedom in how one would define a namespace. >but it's such a pain to change the protocol. Oh, yes! >Seeking on a directory is forbidden because it's hard enough to >implement reading a union directory without seek. What do you mean by "Seeking on a directory" ? As stated in manual ( read(5) ) "The read request message must have offset and count zero modulo DIRLEN.". That's the only restriction. Also I see no restrictions of reading from arbitrary offset in u9fs sources. >The internal >structure that must be maintained in the kernel was deemed too >hard to maintain other than by sequential access, so we made >seeking on a directory illegal. Hmm, I feel I should try to talk with real 9P servers instead of u9fs. >It didn't seem worth the implementation >overhad. I still feel that way. > >>There are a lot of strange things like: >> delim $$ define lbr ' roman "{" ' define rbr ' roman "}" ' >>or >> $CH sub c$ >>which should be "CH c", I guess. > >Would you have noticed this if it didn't contain your name? With first capital letter ? No. :) Thanks, Roman. From owner-9fans@cse.psu.edu Thu Mar 9 14:02:28 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id OAA01093 for 9fans-outgoing; Thu, 9 Mar 2000 14:02:28 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from vitanuova.com (vita-nuova.demon.co.uk [158.152.205.94]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id OAA01088 for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 14:02:20 -0500 (EST) From: forsyth@vitanuova.com Message-Id: <200003091902.OAA01088@cse.psu.edu> To: 9fans@cse.psu.edu Date: Thu, 9 Mar 2000 19:04:21 GMT Subject: Re: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu >> What do you mean by "Seeking on a directory" ? As stated in seek(2) imposes the restriction. the protocol doesn't know about unions, mounts or anything else that might make such a restriction convenient. From owner-9fans@cse.psu.edu Thu Mar 9 16:09:27 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id QAA04174 for 9fans-outgoing; Thu, 9 Mar 2000 16:09:27 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from caldo.demon.co.uk (caldo.demon.co.uk [194.222.207.148]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id QAA04169 for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 16:09:22 -0500 (EST) From: forsyth@caldo.demon.co.uk Message-Id: <200003092109.QAA04169@cse.psu.edu> To: 9fans@cse.psu.edu Date: Thu, 9 Mar 2000 10:39:33 GMT Subject: Re: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu >>I definitely can not understand why openness is persistent property in the >>sense that when I clone the open fid the copy happens to be open too. clone(5) notes that ``The fid [to be cloned]... must not have been opened for I/O by an open or create message''. From owner-9fans@cse.psu.edu Fri Mar 10 04:49:42 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA14084 for 9fans-outgoing; Fri, 10 Mar 2000 04:49:42 -0500 (EST) 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 EAA14075 for <9fans@cse.psu.edu>; Fri, 10 Mar 2000 04:49:35 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12TLs0-0007kF-00 for 9fans@cse.psu.edu; Fri, 10 Mar 2000 09:38:08 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Fri, 10 Mar 2000 09:23:19 GMT From: David Butler Message-ID: <8a97od$72l@library1.airnews.net> Organization: fishnet (using Airnews.net!) References: <200003091350.IAA23914@cse.psu.edu> Subject: Re: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu rob pike wrote in message news:200003091350.IAA23914@cse.psu.edu... > > The real reason for the "lengthy" conversation is the Tclone/Twalk > > part. That is part of the price that is paid to remove the '/' as a > > directory separator > > No. Is that 'no' the conversation is lengthy, 'no' that it is part of the price to remove '/' or 'no' that removing '/' was a goal? [snip] >elements (requiring the server to parse and understand '/'), but >it's such a pain to change the protocol. I hope if you though it "better" it would be worth the "pain". (Not that I think it "better", I don't.) [reorder] > The real reason is that after each walk the client must check whether >the point-so-far is in the mount table. That's why it's done a path [snip] >Seeking on a directory is forbidden because it's hard enough to >implement reading a union directory without seek. The internal By your own point union directories are handled in the Twalk. What does that have to do with reading a directory? >structure that must be maintained in the kernel was deemed too >hard to maintain other than by sequential access, so we made >seeking on a directory illegal. It didn't seem worth the implementation >overhad. Back to the better/pain discussion, again. I thought the limitations to restrictive and worked out a better one. Yes, it was painful, but the result was well worth the effort. > I still feel that way. I'm glad. I won't have to integrate a conflicting solution when, if ever, Release II(TM) sees the light of day... From owner-9fans@cse.psu.edu Fri Mar 10 04:49:46 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA14094 for 9fans-outgoing; Fri, 10 Mar 2000 04:49:46 -0500 (EST) 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 EAA14080 for <9fans@cse.psu.edu>; Fri, 10 Mar 2000 04:49:37 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12TLs1-0007kN-00 for 9fans@cse.psu.edu; Fri, 10 Mar 2000 09:38:09 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Fri, 10 Mar 2000 09:23:50 GMT From: Roman Shaposhnick Message-ID: Organization: St.Petersburg University References: <200003092109.QAA04169@cse.psu.edu> Subject: Re: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu On Thu, 9 Mar 2000 21:27:19 GMT, forsyth@caldo.demon.co.uk wrote: >>>I definitely can not understand why openness is persistent property in the >>>sense that when I clone the open fid the copy happens to be open too. > >clone(5) notes that ``The fid [to be cloned]... must not have been >opened for I/O by an open or create message''. Well, I certainly can read man page. I ask why there is such limitation, not where and how it is described. Sorry, but I would like to discuss bare 9P ( see my previous letter ). Thanks, Roman. From owner-9fans@cse.psu.edu Fri Mar 10 06:03:18 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id GAA14912 for 9fans-outgoing; Fri, 10 Mar 2000 06:03:18 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from caldo.demon.co.uk (caldo.demon.co.uk [194.222.207.148]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id GAA14908 for <9fans@cse.psu.edu>; Fri, 10 Mar 2000 06:03:13 -0500 (EST) From: forsyth@caldo.demon.co.uk Message-Id: <200003101103.GAA14908@cse.psu.edu> To: 9fans@cse.psu.edu Date: Fri, 10 Mar 2000 11:02:24 GMT Subject: Re: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu >>>>>I definitely can not understand why openness is persistent property in the >>>>>sense that when I clone the open fid the copy happens to be open too. >>> >>>clone(5) notes that ``The fid [to be cloned]... must not have been >>>opened for I/O by an open or create message''. >> Well, I certainly can read man page. I ask why there is such limitation, >>not where and how it is described. Sorry, but I would like to discuss bare >>9P ( see my previous letter ). you asked why openness is persistent across clone, and i simply observed that it is not persistent and cannot be, because clone is expressly prohibited on an already open fid. it therefore isn't true that when you `clone the open fid the copy happens to be open too'. it seems you were really asking: why can't i clone an open fid? here is my view (not having actually designed the thing). the operation of Topen, in some file servers, leads to the creation of some server-side state (eg, the state implied by a file descriptor opened in an underlying operating system, in the case of u9fs, or as another example, the state created for an open directory to permit reading it), and that state might not be easily cloned, or not able to be cloned at all (what does it mean to `clone' a file descriptor's state in unix or a file handle's state in Nt?). by contrast, the current Tclone clones state that the server can control and understand completely (eg, local data structures). it's hard enough trying to implement some of the operations as it is! the decomposition of function within 9p (or styx) reduces the scope for unexpected interactions and simplifies the semantics of the protocol's operations, which in turn, can potentially simplify the implementation of both client and server. larger actions are composed of sequences of small, reasonably straightforward primitives. having implemented NFS clients and servers, i quickly came to appreciate the difference! From owner-9fans@cse.psu.edu Sat Mar 11 04:54:30 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA02524 for 9fans-outgoing; Sat, 11 Mar 2000 04:54:29 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from web3202.mail.yahoo.com (web3202.mail.yahoo.com [204.71.202.199]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id EAA02520 for <9fans@cse.psu.edu>; Sat, 11 Mar 2000 04:54:25 -0500 (EST) Message-ID: <20000311095354.25883.qmail@web3202.mail.yahoo.com> Received: from [194.247.215.232] by web3202.mail.yahoo.com; Sat, 11 Mar 2000 01:53:54 PST Date: Sat, 11 Mar 2000 01:53:54 -0800 (PST) From: Vladimir Prokopic Subject: Re: [9fans] Re: 9p question To: 9fans@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 --- Roman Shaposhnick wrote: > and may be there is a chance to get troff sources ? Or this is > restricted > by policy ? > --- presotto@plan9.bell-labs.com wrote: > I'll put a tar out ther. > That's great. Is there a chance to get awk? (Since the source of the true one is released or the port for Plan9 is restricted by policy ? ) Thanks, Vladimir. __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-9fans@cse.psu.edu Sat Mar 11 10:01:15 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id KAA04313 for 9fans-outgoing; Sat, 11 Mar 2000 10:01:15 -0500 (EST) 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 KAA04309 for <9fans@cse.psu.edu>; Sat, 11 Mar 2000 10:01:11 -0500 (EST) Message-Id: <200003111501.KAA04309@cse.psu.edu> From: "rob pike" Subject: Re: [9fans] Re: 9p question Date: Sat, 11 Mar 2000 10:00:57 -0500 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 The source to awk has been available on Brian Kernighan's web page "since the web was invented", according to him. -rob From owner-9fans@cse.psu.edu Sun Mar 12 16:51:28 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id QAA21248 for 9fans-outgoing; Sun, 12 Mar 2000 16:51:28 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from web3205.mail.yahoo.com (web3205.mail.yahoo.com [204.71.202.202]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id QAA21242 for <9fans@cse.psu.edu>; Sun, 12 Mar 2000 16:51:22 -0500 (EST) Message-ID: <20000312215051.6036.qmail@web3205.mail.yahoo.com> Received: from [194.247.215.235] by web3205.mail.yahoo.com; Sun, 12 Mar 2000 13:50:51 PST Date: Sun, 12 Mar 2000 13:50:51 -0800 (PST) From: Vladimir Prokopic Subject: [9fans] awk To: 9fans@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 --- rob pike wrote: > The source to awk has been available on Brian Kernighan's > web page "since the web was invented", according to him. > > -rob > Yes it is. But, what about the Plan9 port of it? Due to the licence - have anyone the right to make it available in public? Thank you Vladimir. __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-9fans@cse.psu.edu Sun Mar 12 17:50:48 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id RAA22140 for 9fans-outgoing; Sun, 12 Mar 2000 17:50:48 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from bio.cse.psu.edu (galapagos.cse.psu.edu [130.203.12.17]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id RAA22136 for <9fans@cse.psu.edu>; Sun, 12 Mar 2000 17:50:43 -0500 (EST) Received: (qmail 13488 invoked by uid 991); 12 Mar 2000 22:50:42 -0000 Message-ID: <20000312225042.13487.qmail@g.bio.cse.psu.edu> Date: 12 Mar 2000 17:50:42 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] awk In-Reply-To: Message from Vladimir Prokopic of "Sun, 12 Mar 2000 13:50:51 PST." <20000312215051.6036.qmail@web3205.mail.yahoo.com> Date: Sun, 12 Mar 2000 17:50:42 -0500 From: Scott Schwartz Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu (Wow... I go on vacation, and the list springs to life.) > But, what about the Plan9 port of it? Conversely, if I recall correctly, the verison that shipped with the second edition wasn't the most recent. Ditto for ksh. Fixed in Brazil? From owner-9fans@cse.psu.edu Sun Mar 12 18:30:08 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id SAA22777 for 9fans-outgoing; Sun, 12 Mar 2000 18:30:07 -0500 (EST) 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 SAA22772 for <9fans@cse.psu.edu>; Sun, 12 Mar 2000 18:30:03 -0500 (EST) From: bobf@plan9.bell-labs.com Message-Id: <200003122330.SAA22772@cse.psu.edu> Date: Sun, 12 Mar 2000 18:29:52 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] awk 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 > Conversely, if I recall correctly, the verison that shipped with the > second edition wasn't the most recent. Ditto for ksh. to answer vladimir's question, the plan 9 port of awk is useless without plan 9: you need plan 9 both to build it and to run it, so there is no reason to release other than as part of the system. the version of awk that we ship is always ported from brian's most recent version in his home directory and is therefore in sync with what brian is currently releasing. we are trying to port the new ksh, but it is a total mess so i don't know if we'll get it done in time, but we are trying. From owner-9fans@cse.psu.edu Sun Mar 12 20:22:15 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id UAA24471 for 9fans-outgoing; Sun, 12 Mar 2000 20:22:15 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from web3204.mail.yahoo.com (web3204.mail.yahoo.com [204.71.202.201]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id UAA24465 for <9fans@cse.psu.edu>; Sun, 12 Mar 2000 20:21:58 -0500 (EST) Message-ID: <20000313012111.4954.qmail@web3204.mail.yahoo.com> Received: from [194.247.215.231] by web3204.mail.yahoo.com; Sun, 12 Mar 2000 17:21:11 PST Date: Sun, 12 Mar 2000 17:21:11 -0800 (PST) From: Vladimir Prokopic Subject: Re: [9fans] awk To: 9fans@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 --- bobf@plan9.bell-labs.com wrote: > the plan 9 port of awk > is useless without plan 9: you need plan 9 both to build > it and to run it, so there is no reason to release other > than as part of the system. I still don 't have the full plan9 - just the pcdist. The precompiled binary should work - if you have the right to make it available. Thanks Vladimir __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-9fans@cse.psu.edu Mon Mar 13 01:25:51 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id BAA29144 for 9fans-outgoing; Mon, 13 Mar 2000 01:25:51 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from fw.softwell.se (root@fw.softwell.se [193.15.236.45]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id BAA29140 for <9fans@cse.psu.edu>; Mon, 13 Mar 2000 01:25:46 -0500 (EST) Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.9.3/8.9.3) with ESMTP id HAA00853 for <9fans@cse.psu.edu>; Mon, 13 Mar 2000 07:25:44 +0100 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id HAA12283 for 9fans@cse.psu.edu; Mon, 13 Mar 2000 07:25:44 +0100 Date: Mon, 13 Mar 2000 07:25:44 +0100 From: Bengt Kleberg Message-Id: <200003130625.HAA12283@trillian.softwell.se> To: 9fans@cse.psu.edu Subject: Re: [9fans] awk Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > From: bobf@plan9.bell-labs.com > we are trying to port the new ksh, but it is a total > mess so i don't know if we'll get it done in time, > but we are trying. Not that I care about ksh, you may leave it and concentrate on other, more important things, so as to make 'it' on time. However, I am _really_ interested in just what it is that oyu want to get done in time. Especially since there has been mentionings before of a new Plan9 version... Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.'' From owner-9fans@cse.psu.edu Mon Mar 13 04:49:55 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA01200 for 9fans-outgoing; Mon, 13 Mar 2000 04:49:54 -0500 (EST) 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 EAA01195 for <9fans@cse.psu.edu>; Mon, 13 Mar 2000 04:49:49 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12URSO-0007Et-00 for 9fans@cse.psu.edu; Mon, 13 Mar 2000 09:48:12 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Mon, 13 Mar 2000 09:28:31 GMT From: "Douglas A. Gwyn" Message-ID: <38CA1F5F.80E629C1@null.net> Organization: @Home Network Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20000311095354.25883.qmail@web3202.mail.yahoo.com> Subject: Re: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Vladimir Prokopic wrote: > Is there a chance to get awk? > (Since the source of the true one is released > or the port for Plan9 is restricted by policy ? ) What is wrong with using the one BWK made available on his Web page (compile under APE)? From owner-9fans@cse.psu.edu Mon Mar 13 07:04:56 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id HAA02333 for 9fans-outgoing; Mon, 13 Mar 2000 07:04:55 -0500 (EST) 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 HAA02328 for <9fans@cse.psu.edu>; Mon, 13 Mar 2000 07:04:50 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12UTXN-00036A-00 for 9fans@cse.psu.edu; Mon, 13 Mar 2000 12:01:29 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Mon, 13 Mar 2000 12:01:18 GMT From: Roman Shaposhnick Message-ID: Organization: St.Petersburg University References: <200003101103.GAA14908@cse.psu.edu> Subject: Re: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu On Fri, 10 Mar 2000 11:24:57 GMT, forsyth@caldo.demon.co.uk wrote: >>>>>>I definitely can not understand why openness is persistent property in the >>>>>>sense that when I clone the open fid the copy happens to be open too. >>>> >>>>clone(5) notes that ``The fid [to be cloned]... must not have been >>>>opened for I/O by an open or create message''. > >>> Well, I certainly can read man page. I ask why there is such limitation, >>>not where and how it is described. Sorry, but I would like to discuss bare >>>9P ( see my previous letter ). > >you asked why openness is persistent across clone, and i simply observed that it is not persistent and cannot be, >because clone is expressly prohibited on an already open fid. it therefore isn't true >that when you `clone the open fid the copy happens to be open too'. No, may be it isn't true, but it isn't false either. I can not speak with real P9 server for now, but u9fs allows me to clone open fids. Please see the following: >> Tstat tag 3 fid 1 << Rstat tag 3 fid 1 + dir >> Topen tag 4 fid 1 mode 0x0 << Ropen tag 4 fid 1 qid 0x81000002.0x38788ddd >> Tclone tag 5 fid 1 newfid 2 << Rclone tag 5 fid 1 That's why I asked question about all that stuff. >it seems you were really asking: why can't i clone an open fid? >here is my view (not having actually designed the thing). > >the operation of Topen, in some file servers, leads to the creation of some server-side >state (eg, the state implied by a file descriptor opened in an underlying operating system, >in the case of u9fs, or as another example, the state created for an open directory to >permit reading it), and that state might not be easily cloned, or not able to be cloned at all >(what does it mean to `clone' a file descriptor's state in unix or a file handle's state in Nt?). >by contrast, the current Tclone clones state that the server can control >and understand completely (eg, local data structures). >it's hard enough trying to implement some of the operations as it is! I believe, that this limitation is a Plan 9 issue not 9P. Something like seek(2) on directories, that is possible in 9P and is forbidden in Plan 9 due to the reasons mentioned here. That's my speculations, but since gurus are not with us and it seems that they are not interested we can not know for certain. :) Thanks, Roman. From owner-9fans@cse.psu.edu Tue Mar 14 05:06:41 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA02695 for 9fans-outgoing; Tue, 14 Mar 2000 05:06:41 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from cssun.mathcs.emory.edu (cssun.mathcs.emory.edu [170.140.150.1]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id FAA02688 for <9fans@cse.psu.edu>; Tue, 14 Mar 2000 05:06:35 -0500 (EST) Received: from compute.mathcs.emory.edu (compute [170.140.150.8]) by cssun.mathcs.emory.edu (8.9.3+Sun/8.9.1) with ESMTP id FAA23908 for <9fans@cse.psu.edu>; Tue, 14 Mar 2000 05:06:33 -0500 (EST) Received: (from arnold@localhost) by compute.mathcs.emory.edu (8.9.3+Sun/8.9.1) id FAA21862; Tue, 14 Mar 2000 05:06:33 -0500 (EST) Date: Tue, 14 Mar 2000 05:06:33 -0500 (EST) From: "Arnold D. Robbins" Message-Id: <200003141006.FAA21862@compute.mathcs.emory.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] awk Newsgroups: comp.os.plan9 In-Reply-To: <20000312225042.13487.qmail@g.bio.cse.psu.edu> References: Organization: Emory University, Dept of Math and CS Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu In article <20000312225042.13487.qmail@g.bio.cse.psu.edu> you write: >(Wow... I go on vacation, and the list springs to life.) Hopefully NOT cause and effect, but one can never tell. :-) Arnold -- Arnold Robbins | If There's More Than One Way To Do It, Guest account at Emory Math/CS | then why is there only one implementation Email: arnold@skeeve.com | of perl? | -- Arnold Robbins From owner-9fans@cse.psu.edu Tue Mar 14 09:49:27 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id JAA06781 for 9fans-outgoing; Tue, 14 Mar 2000 09:49:26 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from vitanuova.com (vita-nuova.demon.co.uk [158.152.205.94]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id JAA06773 for <9fans@cse.psu.edu>; Tue, 14 Mar 2000 09:49:21 -0500 (EST) From: forsyth@vitanuova.com Message-Id: <200003141449.JAA06773@cse.psu.edu> To: 9fans@cse.psu.edu Date: Tue, 14 Mar 2000 14:51:02 GMT Subject: Re: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu >> No, may be it isn't true, but it isn't false either. I can not speak with >>real P9 server for now, but u9fs allows me to clone open fids. Please see >>the following: i'm fairly sure it's a mistake. rclone should set nrf->busy, but didn't. there's otherwise little point in the check made of rbusy by rfilefid (or rclone itself come to that) since only the rattach fid was busy. From owner-9fans@cse.psu.edu Wed Mar 15 00:01:21 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id AAA01185 for 9fans-outgoing; Wed, 15 Mar 2000 00:01:20 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from smtp.fywss.com (84.angoss.com [209.47.149.84] (may be forged)) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id AAA01179 for <9fans@cse.psu.edu>; Wed, 15 Mar 2000 00:01:14 -0500 (EST) Received: (from steve@localhost) by smtp.fywss.com (8.9.3/8.9.3) id AAA06305 for 9fans@cse.psu.edu; Wed, 15 Mar 2000 00:01:00 -0500 Date: Wed, 15 Mar 2000 00:01:00 -0500 From: Steve Kotsopoulos Message-Id: <200003150501.AAA06305@smtp.fywss.com> To: 9fans@cse.psu.edu Subject: [9fans] [reminder] pointer to Plan 9 FAQ Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu The Plan 9 faq is posted to comp.os.plan9 at the beginning of each month. It is also at news.answers archive sites, look for comp-os/plan9-faq The latest hypertext version of the faq is available at url http://www.fywss.com/plan9/plan9faq.html From owner-9fans@cse.psu.edu Thu Mar 16 09:06:07 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id JAA10032 for 9fans-outgoing; Thu, 16 Mar 2000 09:06:06 -0500 (EST) 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 JAA10028 for <9fans@cse.psu.edu>; Thu, 16 Mar 2000 09:06:02 -0500 (EST) From: presotto@plan9.bell-labs.com Message-Id: <200003161406.JAA10028@cse.psu.edu> Date: Thu, 16 Mar 2000 09:05:55 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: 9p question MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-hyltgcvlizbruhaurwogyusgdd" Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu This is a multi-part message in MIME format. --upas-hyltgcvlizbruhaurwogyusgdd Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit By the way, if you ftp, all the troff sources are under plan9/man --upas-hyltgcvlizbruhaurwogyusgdd Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu Mar 9 10:03:46 EST 2000 Received: from cse.psu.edu ([130.203.3.50]) by plan9; Thu Mar 9 10:03:46 EST 2000 Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) with SMTP id JAA25319; Thu, 9 Mar 2000 09:49:49 -0500 (EST) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Thu, 9 Mar 2000 09:49:38 -0500 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id JAA25277 for 9fans-outgoing; Thu, 9 Mar 2000 09:49:33 -0500 (EST) 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 JAA25272 for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 09:49:27 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12T42H-0001GS-00 for 9fans@cse.psu.edu; Thu, 09 Mar 2000 14:35:33 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Thu, 9 Mar 2000 14:21:17 GMT From: Roman Shaposhnick Message-ID: Organization: St.Petersburg University References: <200003091318.IAA23349@cse.psu.edu> Subject: Re: [9fans] Re: 9p question Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk On Thu, 9 Mar 2000 13:36:51 GMT, presotto@plan9.bell-labs.com wrote: >Mea culpa, mea culpa, mea maxima culpa. My troff to html program doesn't >do eqn. Guess I'ld better eqn the pages before running em through. >Thanks for Roman for noticing. Dave, and may be there is a chance to get troff sources ? Or this is restricted by policy ? Thanks, Roman. --upas-hyltgcvlizbruhaurwogyusgdd-- From owner-9fans@cse.psu.edu Mon Mar 20 20:31:09 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id UAA07366 for 9fans-outgoing; Mon, 20 Mar 2000 20:31:09 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from granite.cias.osakafu-u.ac.jp (granite.cias.osakafu-u.ac.jp [157.16.91.52]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id UAA07362 for <9fans@cse.psu.edu>; Mon, 20 Mar 2000 20:31:04 -0500 (EST) From: okamoto@granite.cias.osakafu-u.ac.jp Message-Id: <200003210131.UAA07362@cse.psu.edu> To: 9fans@cse.psu.edu Date: Mon, 21 Mar 1994 10:29:20 +0900 Subject: [9fans] DVD drive support? 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 Well, I've just returned from Houston yesterday, and got DVD recorded many images of Mars in hand. Does new version of Plan9 suport DVD drive? Thanks. Kenji From owner-9fans@cse.psu.edu Mon Mar 20 23:08:27 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id XAA11213 for 9fans-outgoing; Mon, 20 Mar 2000 23:08:26 -0500 (EST) 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 XAA11205 for <9fans@cse.psu.edu>; Mon, 20 Mar 2000 23:08:21 -0500 (EST) From: jmk@plan9.bell-labs.com Message-Id: <200003210408.XAA11205@cse.psu.edu> Date: Mon, 20 Mar 2000 23:08:05 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] DVD drive support? 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 Does new version of Plan9 suport DVD drive? don't know. a couple of weeks ago i tried to mount a dvd in a laptop dvd drive with 9660srv and it mounted fine and i could see a bunch of files. i didn't go any further than that. this was with the ata driver you should have, not anything new. perhaps someone who knows about dvd drives would know if that was expected or if there are any 'gotchas'? --jim From owner-9fans@cse.psu.edu Tue Mar 21 13:06:23 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id NAA27069 for 9fans-outgoing; Tue, 21 Mar 2000 13:06:22 -0500 (EST) 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 NAA27065 for <9fans@cse.psu.edu>; Tue, 21 Mar 2000 13:06:17 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12XT0Z-0005Fm-00 for 9fans@cse.psu.edu; Tue, 21 Mar 2000 18:03:59 +0000 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, 21 Mar 2000 17:56:21 GMT From: "Douglas A. Gwyn" Message-ID: <38D7B549.5607473C@null.net> Organization: @Home Network Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200003210408.XAA11205@cse.psu.edu> Subject: Re: [9fans] DVD drive support? Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu I'm pretty sure that DVD drives act like CD-ROM drives when used with CD-ROMs, but DVD itself (video disk) is supposed to require processing assist from an MPEG decoder (usually a hardware card), so that aspect wouldn't work without special support. What is this about a "new version of Plan 9"? Is Brazil available? Anyway, I would *sure* like Plan 9 on x86 to honor the standard disk partitioning scheme, instead of living in "empty space". From owner-9fans@cse.psu.edu Tue Mar 21 20:03:18 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id UAA09571 for 9fans-outgoing; Tue, 21 Mar 2000 20:03:18 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from granite.cias.osakafu-u.ac.jp (granite.cias.osakafu-u.ac.jp [157.16.91.52]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id UAA09567 for <9fans@cse.psu.edu>; Tue, 21 Mar 2000 20:03:13 -0500 (EST) From: okamoto@granite.cias.osakafu-u.ac.jp Message-Id: <200003220103.UAA09567@cse.psu.edu> To: 9fans@cse.psu.edu Date: Tue, 22 Mar 1994 10:01:26 +0900 Subject: Re: [9fans] DVD drive support? MIME-Version: 1.0 Content-Type: Text/Plain; charset="ISO-2022-JP" Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu >What is this about a "new version of Plan 9"? Is Brazil available? I meant its next release which is now doing developed in Bell Labos. Anyway, I'll try to read DVD-ROM by the present version of Plan 9. Thanks a lot. Kenji From owner-9fans@cse.psu.edu Tue Mar 21 21:17:05 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id VAA11409 for 9fans-outgoing; Tue, 21 Mar 2000 21:17:04 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from wanya.cc.titech.ac.jp (wanya.cc.titech.ac.jp [131.112.14.11]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id VAA11399 for <9fans@cse.psu.edu>; Tue, 21 Mar 2000 21:16:57 -0500 (EST) Received: (qmail 4196 invoked from network); 22 Mar 2000 02:16:47 -0000 Received: from beat.cc.titech.ac.jp (131.112.4.22) by wanya.cc.titech.ac.jp with SMTP; 22 Mar 2000 02:16:47 -0000 Received: (qmail 3818 invoked from network); 22 Mar 2000 02:16:45 -0000 Received: from localhost (HELO beat.cc.titech.ac.jp) (127.0.0.1) by localhost with SMTP; 22 Mar 2000 02:16:45 -0000 From: YAMANASHI Takeshi To: 9fans@cse.psu.edu Subject: Re: [9fans] DVD drive support? In-reply-to: Your message of "Tue, 21 Mar 2000 17:56:21 GMT." <38D7B549.5607473C@null.net> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Wed, 22 Mar 2000 11:16:44 +0900 Message-ID: <3816.953691404@beat.cc.titech.ac.jp> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > Anyway, I would *sure* like Plan 9 on x86 to honor the standard > disk partitioning scheme, instead of living in "empty space". IMHO, such implementation is inevitable to show its "From Outer Space"-ness. -- From owner-9fans@cse.psu.edu Wed Mar 22 03:41:12 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id DAA17794 for 9fans-outgoing; Wed, 22 Mar 2000 03:41:12 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from fw.softwell.se (root@fw.softwell.se [193.15.236.45]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id DAA17790 for <9fans@cse.psu.edu>; Wed, 22 Mar 2000 03:41:07 -0500 (EST) Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.9.3/8.9.3) with ESMTP id JAA23940 for <9fans@cse.psu.edu>; Wed, 22 Mar 2000 09:41:06 +0100 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id JAA15595 for 9fans@cse.psu.edu; Wed, 22 Mar 2000 09:41:05 +0100 Date: Wed, 22 Mar 2000 09:41:05 +0100 From: Bengt Kleberg Message-Id: <200003220841.JAA15595@trillian.softwell.se> To: 9fans@cse.psu.edu Subject: Re: [9fans] DVD drive support? Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > Anyway, I would *sure* like Plan 9 on x86 to honor the standard > disk partitioning scheme, instead of living in "empty space". Actually, it is quite neat. Ie means that it is possible to have 5 OSs installed, despite the standard 4 partitions is max. Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.'' From owner-9fans@cse.psu.edu Wed Mar 22 05:37:01 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA19315 for 9fans-outgoing; Wed, 22 Mar 2000 05:37:01 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from FW-Bochum.Bochum.de (fw-bochum.bochum.de [212.23.128.209]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id FAA19309 for <9fans@cse.psu.edu>; Wed, 22 Mar 2000 05:36:55 -0500 (EST) Received: from FW-Bochum by FW-Bochum.Bochum.de (SMI-8.6/SMI-SVR4) id LAA04414; Wed, 22 Mar 2000 11:28:23 +0100 Received: from Groupwise ([200.100.1.10]) by FW-Bochum.bochum.de; Wed, 22 Mar 2000 11:28:22 +0000 (MET) Received: from GWDCity4-Message_Server by bocity4m1 with Novell_GroupWise; Wed, 22 Mar 2000 11:36:05 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Wed, 22 Mar 2000 11:35:38 +0100 From: AzubiGKD26 To: <9fans@cse.psu.edu> Subject: Antw: Re: [9fans] DVD drive support? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by cse.psu.edu id FAA19310 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu >>> "Douglas A. Gwyn" 21.03.00 18:56:21 >>> > I'm pretty sure that DVD drives act like CD-ROM drives when used > with CD-ROMs, but DVD itself (video disk) is supposed to require > processing assist from an MPEG decoder (usually a hardware card), >so that aspect wouldn't work without special support. Well, ISO 9660 should no problem, but what about native UDF support? Finally an alien filesystem with Unicode! Bye Stefan -- A little suffering is good for the soul. -- Kirk, "The Corbomite Maneuver", stardate 1514.0 From owner-9fans@cse.psu.edu Wed Mar 22 20:21:52 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id UAA15524 for 9fans-outgoing; Wed, 22 Mar 2000 20:21:52 -0500 (EST) 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 UAA15519 for <9fans@cse.psu.edu>; Wed, 22 Mar 2000 20:21:44 -0500 (EST) From: tad@plan9.bell-labs.com Message-Id: <200003230121.UAA15519@cse.psu.edu> Subject: [9fans] Ported MP3 player to Plan9 Date: Wed, 22 Mar 2000 20:21:30 -0500 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 I just ported the MPEG 1, 2, and 3 player from http://www.mpg123.com to Plan9. You can find it at http://www.csh-east.org/~tad/plan9/ Enjoy, -Tad From owner-9fans@cse.psu.edu Thu Mar 23 04:51:27 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA25585 for 9fans-outgoing; Thu, 23 Mar 2000 04:51:27 -0500 (EST) 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 EAA25581 for <9fans@cse.psu.edu>; Thu, 23 Mar 2000 04:51:21 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12Y4C1-0006Tq-00 for 9fans@cse.psu.edu; Thu, 23 Mar 2000 09:46:17 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Thu, 23 Mar 2000 09:35:40 GMT From: Jolt-Freak Message-ID: <38d91cdf.10598827@news.freeserve.net> Organization: Customer of Planet Online References: <200003220841.JAA15595@trillian.softwell.se> Subject: Re: [9fans] DVD drive support? Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu >> Anyway, I would *sure* like Plan 9 on x86 to honor the standard >> disk partitioning scheme, instead of living in "empty space". > >Actually, it is quite neat. Ie means that it is possible to have 5 OSs installed, >despite the standard 4 partitions is max. True, but I think it would be better to choose between the two, then if you only had 1 OS (plan9) you could install it on a partition, but if you needed all the 5 OS's you could also install it in the free space. Jolt-Freak >Best Wishes, Bengt >=============================================================== >Everything aforementioned should be regarded as totally private >opinions, and nothing else. bengt@softwell.se >``His great strength is that he is uncompromising. It would make >him physically ill to think of programming in C++.'' From owner-9fans@cse.psu.edu Fri Mar 24 04:51:38 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id EAA29250 for 9fans-outgoing; Fri, 24 Mar 2000 04:51:38 -0500 (EST) 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 EAA29245 for <9fans@cse.psu.edu>; Fri, 24 Mar 2000 04:51:30 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12YQXs-0000Nr-00 for 9fans@cse.psu.edu; Fri, 24 Mar 2000 09:38:20 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Date: Fri, 24 Mar 2000 09:32:11 GMT From: "Douglas A. Gwyn" Message-ID: <38DAB1C4.F5F3BEFA@null.net> Organization: @Home Network Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200003220841.JAA15595@trillian.softwell.se> Subject: Re: [9fans] DVD drive support? Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Bengt Kleberg wrote: > > Anyway, I would *sure* like Plan 9 on x86 to honor the standard > > disk partitioning scheme, instead of living in "empty space". > Actually, it is quite neat. Ie means that it is possible to have 5 OSs installed, > despite the standard 4 partitions is max. You can use multiple disks in such a case. There really isn't any excuse for Plan 9 on x86 not cooperating with the partitioning scheme used by *all* other x86 OSes, including several flavors of Unix. From owner-9fans@cse.psu.edu Fri Mar 24 05:12:04 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA29654 for 9fans-outgoing; Fri, 24 Mar 2000 05:12:03 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from fw.softwell.se (root@fw.softwell.se [193.15.236.45]) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id FAA29648 for <9fans@cse.psu.edu>; Fri, 24 Mar 2000 05:11:58 -0500 (EST) Received: from trillian.softwell.se (IDENT:bengt@trillian.softwell.se [192.42.172.11]) by fw.softwell.se (8.9.3/8.9.3) with ESMTP id LAA30259 for <9fans@cse.psu.edu>; Fri, 24 Mar 2000 11:11:53 +0100 Received: (from bengt@localhost) by trillian.softwell.se (8.8.7/8.8.7) id LAA24383 for 9fans@cse.psu.edu; Fri, 24 Mar 2000 11:11:53 +0100 Date: Fri, 24 Mar 2000 11:11:53 +0100 From: Bengt Kleberg Message-Id: <200003241011.LAA24383@trillian.softwell.se> To: 9fans@cse.psu.edu Subject: Re: [9fans] DVD drive support? Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu > From: "Douglas A. Gwyn" > There really isn't any excuse for Plan 9 on x86 not cooperating with the partitioning scheme If Plan9 should honour i86 disk layout, should it not also follow sparc/mips/xxx layout too? At the same time? Sounds like a lot of work to me. And it is quite nice to have it at the end of the disk. For instance, I can have a dual boot sparc station. OpenBSD at the front of the disk, plan9 at the end. Best Wishes, Bengt =============================================================== Everything aforementioned should be regarded as totally private opinions, and nothing else. bengt@softwell.se ``His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.'' From owner-9fans@cse.psu.edu Fri Mar 24 05:45:18 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id FAA00238 for 9fans-outgoing; Fri, 24 Mar 2000 05:45:17 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from vitanuova.com (vita-nuova.demon.co.uk [158.152.205.94]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id FAA00234 for <9fans@cse.psu.edu>; Fri, 24 Mar 2000 05:45:12 -0500 (EST) From: forsyth@vitanuova.com Message-Id: <200003241045.FAA00234@cse.psu.edu> To: 9fans@cse.psu.edu Date: Fri, 24 Mar 2000 10:49:11 GMT Subject: Re: [9fans] DVD drive support? Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu who allocates the magic numbers that identify the OS and purpose (eg, linux fs, linux swap) in the partition tables? From owner-9fans@cse.psu.edu Fri Mar 24 09:08:09 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id JAA03266 for 9fans-outgoing; Fri, 24 Mar 2000 09:08:09 -0500 (EST) 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 JAA03250 for <9fans@cse.psu.edu>; Fri, 24 Mar 2000 09:08:02 -0500 (EST) From: jmk@plan9.bell-labs.com Message-Id: <200003241408.JAA03250@cse.psu.edu> Date: Fri, 24 Mar 2000 09:07:52 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] DVD drive support? 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 who allocates the magic numbers that identify the OS and purpose (eg, linux fs, linux swap) in the partition tables? as far as i know there is no authority for this. we chose 0x39 for plan 9. --jim From owner-9fans@cse.psu.edu Fri Mar 24 09:38:08 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id JAA04206 for 9fans-outgoing; Fri, 24 Mar 2000 09:38:07 -0500 (EST) 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 JAA04197 for <9fans@cse.psu.edu>; Fri, 24 Mar 2000 09:38:02 -0500 (EST) 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 GAA19838 for <9fans@cse.psu.edu>; Fri, 24 Mar 2000 06:37:56 -0800 (PST) Received: by symnt3.cadence.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Mar 2000 14:37:36 -0000 Message-ID: <1E485299309FD211A2100090271E27A401AF06DB@symnt3.cadence.com> From: Nigel Roles To: "'9fans@cse.psu.edu'" <9fans@cse.psu.edu> Subject: RE: [9fans] DVD drive support? Date: Fri, 24 Mar 2000 14:37:32 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Received: By mailgate.Cadence.COM as GAA19838 at Fri Mar 24 06:37:56 2000 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu That's all the authority we need I think. -----Original Message----- From: jmk@plan9.bell-labs.com [mailto:jmk@plan9.bell-labs.com] Sent: 24 March 2000 14:08 To: 9fans@cse.psu.edu Subject: Re: [9fans] DVD drive support? who allocates the magic numbers that identify the OS and purpose (eg, linux fs, linux swap) in the partition tables? as far as i know there is no authority for this. we chose 0x39 for plan 9. --jim From owner-9fans@cse.psu.edu Sun Mar 26 22:01:21 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id WAA29807 for 9fans-outgoing; Sun, 26 Mar 2000 22:01:20 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from granite.cias.osakafu-u.ac.jp (granite.cias.osakafu-u.ac.jp [157.16.91.52]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id WAA29803 for <9fans@cse.psu.edu>; Sun, 26 Mar 2000 22:01:16 -0500 (EST) From: okamoto@granite.cias.osakafu-u.ac.jp Message-Id: <200003270301.WAA29803@cse.psu.edu> To: 9fans@cse.psu.edu Date: Sun, 27 Mar 1994 11:59:41 +0900 Subject: RE: [9fans] DVD drive support? MIME-Version: 1.0 Content-Type: Text/Plain; charset="ISO-2022-JP" Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu >That's all the authority we need I think. By the way, I tried to buy a DVD drive, but failed. I was told that it's not easy to get DVD drive now... We seem to be suffering from PlayStation 2 effect here. :-) Kenji From owner-9fans@cse.psu.edu Mon Mar 27 03:37:05 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id DAA04730 for 9fans-outgoing; Mon, 27 Mar 2000 03:37:05 -0500 (EST) 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 DAA04724 for <9fans@cse.psu.edu>; Mon, 27 Mar 2000 03:36:59 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 12ZUp2-0003nB-00 for 9fans@cse.psu.edu; Mon, 27 Mar 2000 09:24:28 +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: Mon, 27 Mar 2000 08:24:04 GMT From: Will Rose Message-ID: <8bi0f3$1q23$1@thoth.cts.com> Organization: CTS Network Services References: <200003220841.JAA15595@trillian.softwell.se>, <38DAB1C4.F5F3BEFA@null.net> Subject: Re: [9fans] DVD drive support? Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Douglas A. Gwyn wrote: : Bengt Kleberg wrote: :> > Anyway, I would *sure* like Plan 9 on x86 to honor the standard :> > disk partitioning scheme, instead of living in "empty space". :> Actually, it is quite neat. Ie means that it is possible to have 5 OSs installed, :> despite the standard 4 partitions is max. : You can use multiple disks in such a case. : There really isn't any excuse for Plan 9 on x86 not cooperating : with the partitioning scheme used by *all* other x86 OSes, : including several flavors of Unix. I started work on this when Plan 9 was first released to the outside world, but never got very far. It doesn't actually seem too difficult, and would be a considerable convenience. If I bring up a Plan 9 system again I'll probably have another shot. Will cwr@cts.com From owner-9fans@cse.psu.edu Thu Mar 30 22:33:54 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id WAA12519 for 9fans-outgoing; Thu, 30 Mar 2000 22:33:53 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from web3205.mail.yahoo.com (web3205.mail.yahoo.com [204.71.202.202]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id WAA12514 for <9fans@cse.psu.edu>; Thu, 30 Mar 2000 22:33:49 -0500 (EST) Message-ID: <20000331033315.20425.qmail@web3205.mail.yahoo.com> Received: from [194.247.215.234] by web3205.mail.yahoo.com; Thu, 30 Mar 2000 19:33:15 PST Date: Thu, 30 Mar 2000 19:33:15 -0800 (PST) From: Vladimir Prokopic Subject: [9fans] NE2000 To: 9fans@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 Is it possible to boot a PC terminal from the NE2000/compatible boot EPROM? Thank' s Vladimir __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-9fans@cse.psu.edu Fri Mar 31 15:02:23 2000 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id PAA02764 for 9fans-outgoing; Fri, 31 Mar 2000 15:02:23 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from akbar.nevex.com (84.angoss.com [209.47.149.84] (may be forged)) by cse.psu.edu (8.8.8/8.8.8) with ESMTP id PAA02759 for <9fans@cse.psu.edu>; Fri, 31 Mar 2000 15:02:17 -0500 (EST) Received: (from steve@localhost) by akbar.nevex.com (8.9.3/8.9.3) id PAA11191 for 9fans@cse.psu.edu; Fri, 31 Mar 2000 15:02:00 -0500 Date: Fri, 31 Mar 2000 15:02:00 -0500 From: Steve Kotsopoulos Message-Id: <200003312002.PAA11191@akbar.nevex.com> To: 9fans@cse.psu.edu Subject: [9fans] http://www.fywss.com/plan9 outage Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu fyi, the machine hosting www.fywss.com will be unavailable from this Sunday morning to Tuesday or Wednesday while we move to a new office.