Date: Sun, 23 Apr 2000 13:14:21 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: SMP changes and breaking kld object module compatibility Message-ID: <200004232014.NAA64138@apollo.backplane.com> References: <200004231909.MAA09128@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:> 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) 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.
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.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004232014.NAA64138>