:Certain places use B_CALL and have biodone() from the b_iodone routine,
:so we can't reliably use B_ASYNC as an indicator of needing to reassign
:to LK_KERNPROC. We have to do it on a case-by-case basis.
:
:It's easier to do cluster_head processing at the point it's gathered
:rather than in BUF_KERNPROC().
:
:vfs_cluster.c is confusing, but I think I've figured out how to get it
:right. I'm not 100% sure about checking for B_CALL in both cases prior
:to VOP_STRATEGY(), and maybe reqbp needs to be considered for the first
:...
There has got to be a better way to do this. This is unbelievably
messy. Please, guys. I am all for stabilizing what was committed
but I just spent a month removing fragility from the buffer cache code,
and this is adding it right back in. This stuff is just too fragile.
Even if we fix it now, it is only going to cause serious problems in
the future.
It looks to me that these hacks exist to get around potential problems
with exclusive lock recursion. We are not *doing* any exclusive lock
recursion right now. I am fairly confident that Kirk can implement
the new softupdates-related elements without having to resort to exclusive
lock recursion, with only a little thought on the matter. Can we please
get rid of the lock reassign junk that only exists to support exclusive
lock recusion and instead go with something simpler? That way we can
remove all of these BUF_KERNPROC calls which have been strewn all over
the code.
We have the luxury of time here, can we please do this implementation
right instead of rushing through making design mistakes?
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
