From owner-cvs-all  Wed Sep  6 10:51:58 2000
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2BE4337B422; Wed,  6 Sep 2000 10:51:55 -0700 (PDT)
Received: (from peter@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id KAA22994;
	Wed, 6 Sep 2000 10:51:55 -0700 (PDT)
	(envelope-from peter@FreeBSD.org)
Message-Id: <200009061751.KAA22994@freefall.freebsd.org>
From: Peter Wemm <peter@FreeBSD.org>
Date: Wed, 6 Sep 2000 10:51:55 -0700 (PDT)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/kern vfs_init.c
X-FreeBSD-CVS-Branch: HEAD
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

peter       2000/09/06 10:51:55 PDT

  Modified files:
    sys/kern             vfs_init.c 
  Log:
  Do not panic on an uninitialized VOP_xxx() call.  This was meant as a
  sanity check, but it is too easy to run into, eg: making an ACL syscall
  when no filesystems have the ACL implementation enabled.
  
  The original reason for the panic was that the VOP_ vector had not been
  assigned and therefor could not be passed down the stack.. and there
  was no point passing it down since nothing implemented it anyway.
  vop_defaultop entries could not pass it on because it had a zero (unknown)
  vector that was indistinguishable from another unknown VOP vector.
  
  Anyway, we can do something reasonable in this case, we shouldn't need
  to panic here as there is a reasonable recovery option (return EOPNOTSUPP
  and dont pass it down the stack).
  
  Requested by: rwatson
  
  Revision  Changes    Path
  1.50      +3 -3      src/sys/kern/vfs_init.c



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message