From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] panic(?) and error(?)
Message-ID: <20020825171415.C29921@cackle.proxima.alt.za>
References: <7195f13865b12345b616627c0edf7651@plan9.bell-labs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <7195f13865b12345b616627c0edf7651@plan9.bell-labs.com>; from presotto@plan9.bell-labs.com on Sun, Aug 25, 2002 at 10:43:27AM -0400
Date: Sun, 25 Aug 2002 17:14:16 +0200
Topicbox-Message-UUID: dff27c60-eaca-11e9-9e20-41e7f4b1d025

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