Re: Vnode life cycle: add vnode state

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   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.

   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?