> On 13. Jul 2022, at 20:33, Taylor R Campbell
> wrote:
>
> Generally looks reasonable to me, assuming it passes the atf tests,
> but give hannken@ another few days to review it?
>
> Maybe instead of adding vnode_impl.h to vfs_vnops.c, we can put the
> vn_knote_* in vfs_vnode.c or create a new
On Wed, 13 Jul 2022, Taylor R Campbell wrote:
Generally looks reasonable to me, assuming it passes the atf tests,
but give hannken@ another few days to review it?
I can confirm that the specific test for 56713 now passes. I have
not done a complete test run.
Generally looks reasonable to me, assuming it passes the atf tests,
but give hannken@ another few days to review it?
Maybe instead of adding vnode_impl.h to vfs_vnops.c, we can put the
vn_knote_* in vfs_vnode.c or create a new file vfs_knote.c, to avoid
having tentacles of vnode guts creep back
When I changed vnode kqueue events to be posted from common code at the VFS
layer, I introduced a regression in sending those events on stacked file
systems like nullfs. The root cause of the problem is that when knotes are
attached to the vnode, that operation (by way of the VOP bypass
