Re: Vnode life cycle: add vnode state

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

> On 20 May 2016, at 18:31, Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
> 
>   Date: Fri, 20 May 2016 16:38:22 +0200
>   From: J. Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost>
> 
>   1) Objects vnode and vcache_node always exist together so it makes sense
>   to merge them into one object.  This can be done in two ways:
> 
>   - Add the current vcache_node elements (hash list, key and flag) to the
>     vnode.
>   - Overlay the vnode into vcache_node.  This way we also get two views
>     to vnodes, a public one (struct vnode) visible from file system
>     implementations and a private one (struct vcache_node) visible from
>     the VFS subsystem (sys/kern/vfs_*) only.
> 
>   I prefer the second way, a diff is here:
>     http://www.netbsd.org/~hannken/vstate/001_merge_vnode_and_vcache_node
> 
> Mild preference for putting the fields in struct vnode -- making a
> bigger structure around it feels sneaky.  But I see the motivation to
> avoid exposing more members than are an intended part of the API, as
> has been done for decades to our constant confusion about what is an
> intended part of the API.
> 
> On the other hand, maybe if we do the second option, it should be not
> vcache_node but vnode_private or something, and we can use it to
> incrementally move more members into it over time to make a usefully
> compiler-checked stable VFS API -- perhaps even eventually make struct
> vnode opaque altogether.

Moving at least the list entries from the public to the private view
is on my agenda.
For now the vcache_node is local to vfs_vnode.c.  Once it has to move
to (the new) sys/vnode_private.h I will do the rename to vnode_private.

>   2) The state of a vnode is currently determined by its flags
>   VI_MARKER, VI_CHANGING, VI_XLOCK and VI_CLEAN.  These flags are not
>   sufficient to describe the state a vnode is in.  It is for example
>   impossible to determine if a vnode is currently attaching to a file system.
> 
> Sounds similar to a sketch I wrote a couple years ago.  I like turning
> inscrutable combinations of flags into explicit states and explicitly
> designed transitions between them.  Can't take a close look right now,
> though.  One tiny question:
> 
>   and these operations to work on the vnode state:
> 
>   - VSTATE_GET(vp): Get the current state.
>   - VSTATE_CHANGE(vp, from, to): Change state.
>   - VSTATE_WAIT_STABLE(vp): Wait until the vnode is in stable state, one of
>     VN_ACTIVE or VN_RECLAIMED.
>   - VSTATE_ASSERT(vp, state): Assert the current state.
> 
> Why uppercase?  Are these macros?  If so, why not (inline) functions?

These are all macros to get better diagnostics.  In the DIAGNOSTICS
case they expand to functions propagating name and line number of
the caller.

--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)