:>     There's another good reason to MFC the linux patch on wednesday... 
:>     that is, to do it at the same time the SMP cleanup is MFC'd, and that
:>     is because both patch sets require the linux kernel module to be 
:>     recompiled and I'd rather not force people to do that twice. 
:>     The SMP patchset, in fact, requires that all kernel modules be 
:>     recompiled due to the locks that were removed from the spl*() macros.
:In that case I have a strong objection to the SMP patchset being
:merged to 4.0.  I have kernel modules in object format only that
:are working now, which this would break :-(.
:Rod Grimes - KD7CAX @ CN85sl - (RWG25)               [EMAIL PROTECTED]

    This is a legitimate topic for discussion.

    In general I agree with the concept but I think .0 releases have to 
    have a bit more flexibility, and that 4.0 in particular (due to the 
    rules change made for the BSDI merger) has to be even more flexible.  
    We should be allowed to break kernel module loader compatibility
    in between a .0 and a .1 release if it is deemed necessary, but that
    it should be avoided (as much as possible) after the .1 release.

    I would put forth that the SMP patches are a special case in that they
    provide a base for which further BGL unwinding can occur in both 4.x
    and 5.x without further API breakages (beyond this one).  If we do not
    MFC the SMP cleanup, then there is no chance of being able to MFC 
    *ANY* further SMP-related lock removal or performance work 
    from 5.x to 4.x.  

    I believe that it is fairly important to try to extend the SMP work
    into 4.x as much as possible, otherwise certain significant performance
    improvements that might be made in a very unstable 5.x will not be
    available to the general public in the stable 4.x for another year.  I
    expect most production machines will be running 4.x for at least the
    year and a half.  To be blunt, if we don't do this now then we are
    going to be behind the competition (linux, solaris) for much too long.

    As an example of how important this can be I would point back to the
    3.x and 4.x trees during the VM work I did.  By not MFCing from the
    outset we reached a point where bug fixes going into 4.x could *not*
    be backported to 3.x without a lot of work.  We reached a point 
    where bug fixes (garbage after file EOF in mmaps for example) simply 
    could not be backported, or required a lot of work (some of the NFS fixes
    had to be rewritten for 3.x).

    I think it may be even more important for 4.x and 5.x in regards to 
    the SMP work.

                                        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