Totally off topic question that I've wondered for some time now - what
does MFC stand for?

Thanks for humoring my ignorance, and thanks for all your hard work on


On Sun, 23 Apr 2000, Matthew Dillon wrote:

> Date: Sun, 23 Apr 2000 13:31:34 -0700 (PDT)
> From: Matthew Dillon <[EMAIL PROTECTED]>
> To: Richard Wackerbarth <[EMAIL PROTECTED]>
> Subject: Re: SMP changes and breaking kld object module compatibility
> :
> :On Sun, 23 Apr 2000, Matthew Dillon wrote:
> :
> :> :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)              
> :>
> :>     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.
> :
> :Rather than break the FreeBSD4 modules over which you have no control,
> :perhaps your arguments should be used to accelerate the 5.0 release
> :and make 4.x a short lived branch.
>     I don't think this is possible.  4.0 is the most stable release we've
>     ever had, and I am confident that the 4.x series of releases will be
>     the best in FreeBSD's history probably until 5.1 or 5.2.
>     5.x is going to be seriously torn up.  Maybe not as bad as people thought,
>     but still seriously torn up.  It's already being torn up.  I don't think
>     there is any chance of making 4.x a short-lived branch nor do I think
>     we want to.  We should bask in the light of finallly having a good stable,
>     high performance set of 4.x releases.
>     What we have is a war between the customer's need for stability,
>     other customer's need for speed, and the realities that developers 
>     face in not wanting to have to rewrite patches in order to MFC them,
>     and wanting to have the opportunity to MFC improvements and bug fixes
>     in the first place.  The SMP patch falls somewhere in the middle, and 
>     I am aiming it towards the MFC side to make #3 easier.
>                                       -Matt
>                                       Matthew Dillon 
>                                       <[EMAIL PROTECTED]>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

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

Reply via email to