Date: Tue, 12 Feb 2019 07:22:26 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: cem@freebsd.org Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: RFC: What to do about VOP_INACTIVE? Message-ID: <86316.1549956146@critter.freebsd.dk> In-Reply-To: <CAG6CVpU8J=G8za8W2uan8SAGEbe4PD=SXwMow=E_mkJnMGB96A@mail.gmail.com> References: <CAG6CVpU8J=G8za8W2uan8SAGEbe4PD=SXwMow=E_mkJnMGB96A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--------
In message <CAG6CVpU8J=3DG8za8W2uan8SAGEbe4PD=3DSXwMow=3DE_mkJnMGB96A@mail=
.gmail.com>, Conrad Meyer writes:
>The nominal return type of the VOP_INACTIVE vnode method is 'int', but
>in practice any error returned is silently discarded.
The return type is an historical accident from John Heidemann's phd.
The way he implemented stackable filesystems cast all VOP's to:
typedef int vop_t __P((void *));
So that filesystems could have a VOP methodvector which looked like:
static struct vnodeopv_entry_desc fifo_vnodeop_entries[] =3D {
{ &vop_default_desc, (vop_t *) vn_default_error },
{ &vop_abortop_desc, (vop_t *) fifo_badop },
{ &vop_access_desc, (vop_t *) fifo_ebadf },
{ &vop_advlock_desc, (vop_t *) fifo_advlock },
[...]
Then on runtime, he built the real vop dispatch tables.
Around 1997 I untangled that so that we got compiler type-checks
all the way though the VOP calls, and there were enough historical
cruft to clean up that I never got around to the return type of
the individual VOPs.
If you want to fix this, the right thing to do is to add return types
in vnode_if.src and teach the tools/vnode_if.awk script about them.
-- =
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe =
Never attribute to malice what can adequately be explained by incompetence=
.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86316.1549956146>