:Hmm. Ok, so right now the code that has been branched for DP1 makes use
:of Brian's recent locking commits. My original thought was we'd simply
:back it out of that branch to make sure that the DP is reliable. How hard
:would it be for us to switch to what you propose (just convert all slocks
:into xlocks, and simplify out the upgrade semantics), in particular,
:before we cut the DP? It sounds to me like the right approach is simply
:to fall back to lockmgr for the DP, and get these fixes into the main tree
:and they'll be there for the next DP in a few months.
:
:Can you take ownership of the task since you clearly know what's going on?
:Can I stick your name in the smp web page saying so? :-)
:
:Robert N M Watson FreeBSD Core Team, TrustedBSD Project
:[EMAIL PROTECTED] NAI Labs, Safeport Network Services
I think the developers currently working on it have the expertise to
clean it up. My recommendation is that developer who committed the
SX lock stuff back it out (fall back to the lockmgr locks), and then
that same developer scan the code and determine if the lockmgr lock
can just be made exclusive for all cases and, if so, to test and
commit that. If the exclusive-only lockmgr lock works then that is
what should go into the DP, else the original lockmgr stuff should go
in.
Until the critical_*() function issue is resolved I do not want to
make extensive modifications or updates to my -current tree so I couldn't
do this stuff in the time frame you are talking about even if I wanted
to.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
