Re: [9fans] panic(?) and error(?)

Re: [9fans] panic(?) and error(?)

[presotto]

Error() in upas/fs.c just exits the process after printing a message.
I didn't use sysfatal() because I want to kill off the entire process
group on error and sysfatal doesn't.  If I'ld used the thread package
I wouldn't have needed to do it that way.

It is totally unrelated to the error() in the kernel nor
error() in 9660srv.  They implements an exception
stack so that they can cleanly back out of errors without
crashing.

The similarity in name implies nothing about similarity in
function.

Re: [9fans] panic(?) and error(?)

[Lucio De Re]

On Sun, Aug 25, 2002 at 10:43:27AM -0400, presotto@plan9.bell-labs.com wrote:
>
> Error() in upas/fs.c just exits the process after printing a message.
> I didn't use sysfatal() because I want to kill off the entire process
> group on error and sysfatal doesn't.  If I'ld used the thread package
> I wouldn't have needed to do it that way.
>
Did I perhaps miss a definition of error() local to upas/fs?  I could
easily have.

> It is totally unrelated to the error() in the kernel nor
> error() in 9660srv.  They implements an exception
> stack so that they can cleanly back out of errors without
> crashing.
>
9660srv uses panic() - again, I didn't think of looking for a local
definition - which takes a first argument that resembles an fd that
ought to be redirected to /dev/null.  That bit of logic baffles me.

> The similarity in name implies nothing about similarity in
> function.

I would make myself very unpopular if I mentioned that in studying
9p(2) and colleagues, I came to the conclusion that it would be
clearer in C++.  So I'll keep such thoughts to myself.  :-)  :-)

Namespace pollution caught me here, I'll go and do some additional
snooping.  Thanks for the clarification.

++L

Re: [9fans] panic(?) and error(?)

[Lucio De Re]

On Sun, Aug 25, 2002 at 10:43:27AM -0400, presotto@plan9.bell-labs.com wrote:
>
> Error() in upas/fs.c just exits the process after printing a message.

I note now that panic() in 9660srv actually uses the "rflag" as an
indicator of whether to print the syserror message or not.  I think
I'll be more methodical in my explorations in future.

++L

Re: [9fans] panic(?) and error(?)

[Lucio De Re]

On Sun, Aug 25, 2002 at 11:31:15AM -0400, presotto@plan9.bell-labs.com wrote:
>
> Try using grep.  It's amazingly useful since we (bel labs

My brain may be a useful tool too, if only I could rely on it :-(

Sadly, it's hard to figure out what is a trivial question and what
is a legitimate one and I have a penchant to err on the side that
makes a fool of me :-)

++L

Re: [9fans] panic(?) and error(?)

[presotto]

Try using grep.  It's amazingly useful since we (bel labs
crowd) use the convention of starting our routine defnitions
with the name on the left margin:

% cd /sys/src/cmd/9660srv
% grep -n '^(panic|error)' *.c
main.c:223: error(char *p)
main.c:558: panic(int rflag, char *fmt, ...)
% cd /sys/src/cmd/upas/fs
% grep -n '^(panic|error)' *.c
fs.c:1259: error(char *s)

Works well in the editor also.

[9fans] panic(?) and error(?)

[Lucio De Re]

I'd like some descriptions for functions error() and panic() as used
in /sys/src/cmd/9660srv/main.c and /sys/src/cmd/upas/fs/fs.c
respectively - and elsewhere, no doubt.

The arguments are different and I'm having difficulty understanding
whether they are functionally similar but retained for historical
reasons (what would be the "modern" equivalent?) or whether in fact
the choice depends on the context.

I note that 9660srv closes fds 0 and 1 and reopens them in the most
harmless manner (/dev/null), which upas/fs does not do and I wonder
if these are influencing the choice of error reporting.

Of course, I do have the source to consult, but little guidance on
where to look, even.

++L