From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: David Presotto To: 9fans@cse.psu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-lfoexntmivnnykjjfrectonhxm" Subject: [9fans] (no subject) Date: Tue, 17 Feb 2004 09:26:51 -0500 Topicbox-Message-UUID: e8668740-eacc-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-lfoexntmivnnykjjfrectonhxm Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think taking out the counts in the stats of streaming files was a mistake. Even though we have fd2path, there is not path that yields another file to get this info for pipes since pipes aren't in your namespace and I don't think putting them in the ns is a good idea. I'm going to put the counts back, but with a vengeance. Before it only worked for uarts, pipes, and tcp connections. This time I'll make it work for all streamed connections. As for telling whether a file is seekable, I'm finding myself leaning toward what I didn't like before, i.e., info that comes out of dirfstat. However I'ld prefer the flag say that files are streaming rather than seekable so that I don't have to change as much (in fact only what I have to change anyways). Comments? --upas-lfoexntmivnnykjjfrectonhxm Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Tue Feb 17 00:25:25 EST 2004 Received: from collyer.net ([63.192.14.226]) by plan9; Tue Feb 17 00:25:24 EST 2004 Message-ID: subject: not reporting queue length in stat length breaks event(2) From: Geoff Collyer Date: Mon, 16 Feb 2004 21:25:22 -0800 To: 9trouble@plan9.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think we should revert to the old behaviour. ecanread(), for example, is now never true because it looks at the stat length of a pipe. I think the old behaviour is just too useful to lose. --upas-lfoexntmivnnykjjfrectonhxm--