From owner-cvs-sys Wed Apr 16 05:27:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA24062 for cvs-sys-outgoing; Wed, 16 Apr 1997 05:27:55 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA24056; Wed, 16 Apr 1997 05:27:51 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.5/3.4W4) with ESMTP id VAA15848; Wed, 16 Apr 1997 21:22:00 +0900 (JST) Message-Id: <199704161222.VAA15848@gneiss.eps.nagoya-u.ac.jp> To: darrenr@cyber.com.au Cc: michaelh@cet.co.jp, CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/miscfs/union union_vnops.c In-Reply-To: Your message of "Wed, 16 Apr 1997 18:51:15 +1000 (EST)" References: <199704160851.SAA09685@plum.cyber.com.au> X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 16 Apr 1997 21:21:59 +0900 From: KATO Takenori Sender: owner-cvs-sys@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I cannot object against both opinions. Kernel hackers may prefer panic to inter-process hang because panic and stack trace could help to find problems. Most users may prefer inter-process hang to panic because they can obtain a chance to sync filesystems. I think that we should chose one of them as the case may be. From: Darren Reed Subject: Re: cvs commit: src/sys/miscfs/union union_vnops.c Date: Wed, 16 Apr 1997 18:51:15 +1000 (EST) > In some mail I received from Michael Hancock, sie wrote > > > > I saw that you found the real fix later. Cool. > > > > Regarding the below, I think it's better to panic in this case. Making > > things robust often works against making it work correctly. Consistency > > checks that result in panics are there to help you find problems. Working > > around consistency checks usually results in crufty code. > > A system that is up is a good thing. > > If a systems admin. can crash it by typing a mount command (for example) > incorrectly, that is bad (IMHO). I see what you're getting at but I'd > prefer it to return a nasty error. ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) -------------------