: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

    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

                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to