summaryrefslogtreecommitdiffstats
path: root/sys/alpha/tlsb/dwlpxvar.h
diff options
context:
space:
mode:
authorpeter <peter@FreeBSD.org>2000-09-06 17:51:54 +0000
committerpeter <peter@FreeBSD.org>2000-09-06 17:51:54 +0000
commit526b3ccc0d89aac616c45387d5f5dd5d65832e70 (patch)
treeea36f1e6f9d9db5e5a4e6d9b9c0a31518aafc9de /sys/alpha/tlsb/dwlpxvar.h
parent93fc8a1033b7da4a910f6786e5aa4480a95e1af4 (diff)
downloadFreeBSD-src-526b3ccc0d89aac616c45387d5f5dd5d65832e70.zip
FreeBSD-src-526b3ccc0d89aac616c45387d5f5dd5d65832e70.tar.gz
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
Diffstat (limited to 'sys/alpha/tlsb/dwlpxvar.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud