[9fans] (no subject)

[9fans] (no subject)

[David Presotto]

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

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?

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

From: Geoff Collyer <geoff@collyer.net>
To: 9trouble@plan9.bell-labs.com
Subject: not reporting queue length in stat length breaks event(2)
Date: Mon, 16 Feb 2004 21:25:22 -0800
Message-ID: <d061185b4255887f0da683074b405a8f@collyer.net>

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.

Re: [9fans] (no subject)

[Rob Pike]

> 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).

i still believe it's not worth the trouble to fix, that you're making a
mountain
out of a molehill.  if you decide to add the bit, it's a
locally-defined bit so make
zero the right answer for most files and then the local drivers can set
it. it'll
be a real headache tracking down everything and making sure it's
forwarded
everywhere and so on and so on.

i think it's a mistake.  you'll be futzing with it for years.

-rob

Re: [9fans] (no subject)

[David Presotto]

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

I think that's what my message said.  Am I misunderstanding something somewhere?

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

From: Rob Pike <rob@mightycheese.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] (no subject)
Date: Tue, 17 Feb 2004 08:13:06 -0800
Message-ID: <2B944522-6164-11D8-A6FF-000A95B984D8@mightycheese.com>

> 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).

i still believe it's not worth the trouble to fix, that you're making a
mountain
out of a molehill.  if you decide to add the bit, it's a
locally-defined bit so make
zero the right answer for most files and then the local drivers can set
it. it'll
be a real headache tracking down everything and making sure it's
forwarded
everywhere and so on and so on.

i think it's a mistake.  you'll be futzing with it for years.

-rob

Re: [9fans] (no subject)

[Rob Pike]

> I think that's what my message said.  Am I misunderstanding something
> somewhere?

it sounded like you were proposing to add a bit to the stat permission
bits.
i was demurring.

-rob

[9fans] profiling

[rog]

has anyone used the profiler (not tprof) recently?

i get a suicide when trying to run the simplest programs,
and was wondering whether it's a local problem or not.

e.g.

% cat tst.c
#include <u.h>
#include <libc.h>
void
main(int argc, char **argv)
{
}
% 8c -c tst.c
% 8l -p tst.8
% 8.out
8.out 863: suicide: sys: trap: fault read addr=0x7ffff014 pc=0x000017c1
% db 863
386 binary
page fault
/sys/src/libc/port/profile.c:235 _profmain+1d/               	REP MOVSL	(SI),(DI)
$C
_profmain() /sys/src/libc/port/profile.c:229 called from _mainp+22 /sys/src/libc/386/main9p.s:13
       	_profmain.n/         	0x7d0
       	_profmain..safe/         	0x0
       	_profmain.f/         	0x0
       	_profmain.ename/         	0x0

Re: [9fans] profiling

[rob pike, esq.]

works fine for me, although i'm a little behind the curve.

i do notice that the  profile is now labeled by pid, which
is clean i suppose but forces you to specify the file name,
which you must first discover, to prof.  why not use prof.out
if there's no such file already?

Re: [9fans] profiling

[David Presotto]

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

I just did from a system built from sources and it worked fine.

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

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: [9fans] profiling
Date: Tue, 17 Feb 2004 16:59:35 0000
Message-ID: <9e616fb26ccca7ac477eeb4e934dd091@vitanuova.com>

has anyone used the profiler (not tprof) recently?

i get a suicide when trying to run the simplest programs,
and was wondering whether it's a local problem or not.

e.g.

% cat tst.c
#include <u.h>
#include <libc.h>
void
main(int argc, char **argv)
{
}
% 8c -c tst.c
% 8l -p tst.8
% 8.out
8.out 863: suicide: sys: trap: fault read addr=0x7ffff014 pc=0x000017c1
% db 863
386 binary
page fault
/sys/src/libc/port/profile.c:235 _profmain+1d/               	REP MOVSL	(SI),(DI)
$C
_profmain() /sys/src/libc/port/profile.c:229 called from _mainp+22 /sys/src/libc/386/main9p.s:13
       	_profmain.n/         	0x7d0
       	_profmain..safe/         	0x0
       	_profmain.f/         	0x0
       	_profmain.ename/         	0x0

Re: [9fans] (no subject)

[C H Forsyth]

perhaps it was `ecanread' existing that was wrong.

Re: [9fans] profiling

[Charles Forsyth]

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

it's fine at home.
my guess is it's because in the office the the top o' the stack format
differs twixt library and kernel.   i suspect _tos->cyclefreq
isn't a valid reference for that version of the kernel, even though the
libraries are new.   i'll update the floppy and
reboot the office machine when i get back in tomorrow.

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

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

I just did from a system built from sources and it worked fine.

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

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: [9fans] profiling
Date: Tue, 17 Feb 2004 16:59:35 0000
Message-ID: <9e616fb26ccca7ac477eeb4e934dd091@vitanuova.com>

has anyone used the profiler (not tprof) recently?

i get a suicide when trying to run the simplest programs,
and was wondering whether it's a local problem or not.

e.g.

% cat tst.c
#include <u.h>
#include <libc.h>
void
main(int argc, char **argv)
{
}
% 8c -c tst.c
% 8l -p tst.8
% 8.out
8.out 863: suicide: sys: trap: fault read addr=0x7ffff014 pc=0x000017c1
% db 863
386 binary
page fault
/sys/src/libc/port/profile.c:235 _profmain+1d/               	REP MOVSL	(SI),(DI)
$C
_profmain() /sys/src/libc/port/profile.c:229 called from _mainp+22 /sys/src/libc/386/main9p.s:13
       	_profmain.n/         	0x7d0
       	_profmain..safe/         	0x0
       	_profmain.f/         	0x0
       	_profmain.ename/         	0x0

Re: [9fans] (no subject)

[Charles Forsyth]

>>vengeance.  Before it only worked for uarts, pipes, and tcp connections.  This
>>time I'll make it work for all streamed connections.

streamed connections?  i didn't know we had streamed connections.
i tought we were an autonomous coll... sorry.
i thought files were intended to lack access methods.
isn't it really that (a) tail was transliterated from unix
and (b) it cheats (not reading the Wretched File from
start to finish) that there's a problem at all.
otherwise, i don't think you go far enough: DMPIPE, DMNET, DM9NUT,
these are the things we need.

Re: [9fans] (no subject)

[David Presotto]

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

DMSEEKCAUSESTAPETOSPINANDCOMEOFFSPINDLE

I can't think of anything that really makes sense so I'm just leaving
things the way they used to be.  Rob is right.

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

From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] (no subject)
Date: Tue, 17 Feb 2004 23:57:47 0000
Message-ID: <b7bb09d1d797aa297942132217e48b06@terzarima.net>

>>vengeance.  Before it only worked for uarts, pipes, and tcp connections.  This
>>time I'll make it work for all streamed connections.

streamed connections?  i didn't know we had streamed connections.
i tought we were an autonomous coll... sorry.
i thought files were intended to lack access methods.
isn't it really that (a) tail was transliterated from unix
and (b) it cheats (not reading the Wretched File from
start to finish) that there's a problem at all.
otherwise, i don't think you go far enough: DMPIPE, DMNET, DM9NUT,
these are the things we need.

Re: [9fans] (no subject)

[boyd, rounin]

any number between 1 and 9 seekable bits is a pint [bad].

Re: [9fans] (no subject)

[9nut]

> otherwise, i don't think you go far enough: DMPIPE, DMNET, DM9NUT,

Wahoo!

"The new phonebooks are here! The new phonebooks are here! My name
is in print! I am SOMEBODY now."
	-- Steve Martin, "The Jerk"

Re: [9fans] (no subject)

[rog]

> (b) it cheats (not reading the Wretched File from start to finish)

it might be a cheat, but it's a darn useful one.

for instance, on my outgoing mail file, tail took <0.02 seconds;
reading the entire file took >10 minutes (lots of it was on the worm).

the same kind of thing applies to other situations when using a file
bigger than one would like to keep in memory, but which isn't possible
to process sequentially.

of course, faced with this kind of thing, one just goes ahead and
guesses (as tail and diff do)...  only for it to have to potential to
go wrong at some unforeseen time in the future.

i suppose one could make such commands default to the safe mode, and
give them an option that says the file is seekable.

i guess i thought there was the potential to do better.