Date: Sun, 23 Apr 2000 13:31:34 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Richard Wackerbarth <rkw@dataplex.net> Cc: freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility Message-ID: <200004232031.NAA64273@apollo.backplane.com> References: <200004231909.MAA09128@gndrsh.dnsmgr.net> <200004232014.NAA64138@apollo.backplane.com> <00042315214900.24082@nomad.dataplex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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)
:> : rgrimes@gndrsh.dnsmgr.net
:>
:> 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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004232031.NAA64273>