OpenSolaris

Depending on what functionality the FEM monitor provides, it is necessary that
the (vnode events)vnevents callback, by the file system, occur pre file 
operation or post file operation.  

This has been uncovered trying to address some of the issue originating due
to when the vevents call backs happen. The nfsv4 delegation monitor requires
that the vnevent call back occur prior to the file operation(Ref 6602216, 6195111). 
Where as the File Events Notification monitor requires that the vevents call back
occur post file operation and only if the file operation is successful(See 6636438,6636412).

In order to satisfy both type of requirements, the VOP_VNEVENT() and the
vnevent** call back routine should be extended to be pre and post routines. Also
make provision to pass additional information like error and result of the file 
operation so that the FEM monitor as well as the file system can take 
appropriate action.

Currently, the vnevent interfaces do not specify when to call them. As a result
the vnevent call backs implemented in the different file systems are inconsistent.

These enhancements are required to address the File Events Notification issues
6636438 & 6636412.

N/A

storing some observation occured during a discussion about how to intercept a pathname prior a VOP occuring (to
give this some context)

if in kernel land, it is (actually was till writing this email) my current understanding 
that the only way to intercept a VOP (and thus it's arguments like a path name for VOP_CREATE(),
VOP_MKDIR(), VOP_LOOKUP()) would be a FEM monitor in general.
 
but some file systems like UFS and other legacy ones do not do that right, they
create the event after the VOP has finished (refer to: 6602216 )
VxFS ( see 6581120 ) and ZFS get this mostly correct, 
ie. prior the namespace manipulation)
 
although for example in the zfs_create() case, I can see for the truncate case, that
the event is triggered after the operation like in UFS. But what I can not
find in zfs_create() or ufs_create() is a monitor triggered for the regular create case, 
I don't see a matching vnevent_create() for that case at all.
 
in user land, VNEVENTS would do similar, however as they are implemented today,
most of them happen to occur after the name space manipulation by design, ie.
after the VOP has changed. although there was already debatte to bring
those 2 (FEM/VNEVENT and File Event Notifications or whatever they are called these days 
together -> see 6651501 )
 
to complicate matters now look at the nfs client, eg. nfs4_create() which 
is what you likely want to intercept to grab the to be created name prior
the action (OTW call) happening).
 
it'll post the vnevent_create() for the truncate file creation case,
but like in ZFS and UFS - I do not see an event triggered for the regular create case,
when it really does the OTW op. but thats presumably what would be of interest for you.
 
VOP_MKDIR on the other hand does not seem to trigger events at all, neither ufs_mkdir()
nor zfs_mkdir() do anything here, there's not even a vnevent_mkdir() callback yet.
 
and since you mentioned hard links, ie. VOP_LINK(), ufs_link() posts the even after
the name space manipulation, so does zfs_link() and even the nfs client as well in
nfs4_link().
 
it looks like over time, the inital FEM based support for NFS delegations ( PSARC/2004/170 / Rfe 4979723 )
and the File Event Notification API ( PSARC 2007/027 / Rfe 6367770 )
created an inconsistant behavior over all VOPs, some or not even included like VOP_MKDIR as opposed to VOP_RMDIR
(why do we want to know the deletion of a directory but not the creation of the same
is mystery to me in the context of File Event Notifications though...)