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
FreeBSD...
:)
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]>
> Cc: [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)
> :> : [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.
> :
> :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
