From owner-freebsd-current Sun Apr 23 13:14:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 07B2637BA1F; Sun, 23 Apr 2000 13:14:25 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA64138; Sun, 23 Apr 2000 13:14:21 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 13:14:21 -0700 (PDT) From: Matthew Dillon Message-Id: <200004232014.NAA64138@apollo.backplane.com> To: "Rodney W. Grimes" 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 References: <200004231909.MAA09128@gndrsh.dnsmgr.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message