diff options
author | peter <peter@FreeBSD.org> | 2000-09-06 17:51:54 +0000 |
---|---|---|
committer | peter <peter@FreeBSD.org> | 2000-09-06 17:51:54 +0000 |
commit | 526b3ccc0d89aac616c45387d5f5dd5d65832e70 (patch) | |
tree | ea36f1e6f9d9db5e5a4e6d9b9c0a31518aafc9de /sys/alpha/tlsb/dwlpxvar.h | |
parent | 93fc8a1033b7da4a910f6786e5aa4480a95e1af4 (diff) | |
download | FreeBSD-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