From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 02:37:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8CC2106564A; Thu, 8 Jul 2010 02:37:12 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailD.acsu.buffalo.edu (localmailD.acsu.buffalo.edu [128.205.5.208]) by mx1.freebsd.org (Postfix) with ESMTP id A39E38FC17; Thu, 8 Jul 2010 02:37:12 +0000 (UTC) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B64D3C186F; Wed, 7 Jul 2010 22:37:06 -0400 (EDT) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailD.acsu.buffalo.edu (Postfix) with ESMTP id 9BD69C187C; Wed, 7 Jul 2010 22:37:05 -0400 (EDT) Received: from mweb1.acsu.buffalo.edu (mweb1.acsu.buffalo.edu [128.205.5.238]) by localmailD.acsu.buffalo.edu (Prefixe) with ESMTP id 90992C1860; Wed, 7 Jul 2010 22:37:05 -0400 (EDT) Received: from ken-smiths-macbook-pro.local (cpe-76-180-182-44.buffalo.res.rr.com [76.180.182.44]) by mweb1.acsu.buffalo.edu (Postfix) with ESMTP id 0A5155B0038; Wed, 7 Jul 2010 22:37:04 -0400 (EDT) Message-ID: <4C3539CD.10204@buffalo.edu> Date: Wed, 07 Jul 2010 22:37:01 -0400 From: Ken Smith User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: "Mikhail T." References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> In-Reply-To: <4C34E0E6.9070801@aldan.algebra.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-PM-EL-Spam-Prob: XX: 27% Cc: re@freebsd.org, tom@hur.st, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org, Jeremy Chadwick Subject: Re: 8.x grudges X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 02:37:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/7/10 4:17 PM, Mikhail T. wrote: > 07.07.2010 14:59, Jeremy Chadwick написав(ла): >>> FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and >>> thus not an "option") -- the kernel-config files, that worked with >>> 7.x, break without this option in them (in addition to all the >>> nuisance, that's documented in UPDATING -- which, somehow, makes >>> the breakage acceptable). config(8) would not warn about this, but >>> kernel build fails. >>> >> We don't use this option (meaning it's removed from our kernels). It's >> definitely not required. All it does is ensure your kernel can >> comprehend executables/binaries built on 7.x. >> > Attached is the kernel config-file (i386), that worked fine under 7.x. > The kernel-compile will break (some *freebsd7* structs undefined), > without the COMPAT_FREEBSD7 option. Try it for yourself... Jeremy is correct. COMPAT_FREEBSD7 means, despite this being FreeBSD 8, set things that have changed up to work in a way that is compatible with FreeBSD 7 *wherever* *possible*. Since you are trying to use a FreeBSD 7 based kernel config file you need that option, but people not trying to hold on to the FreeBSD 7 ways of doing things do not need that option. I'm not quite sure why you find that surprising, though it may have to do with a mis-conception on your part described below. >> The way I do this is, when upgrading major releases (7.x->8.x), to >> "start fresh" using GENERIC as my base template and then >> adding/adjusting while comparing against the older kernels' config. >> Others do it differently, this is just how I do it. >> > Yes, your way is fine. But so is mine. It is perfectly reasonable to > expect my method to work just as well -- the 7->8 is not revolutionary, > but simply the next step. I read the "UPDATING" file and, though annoyed > a little, took care of things mentioned in there... The remaining things > are enumerated here... Actually it's not perfectly reasonable to *expect* your method to work just as well given the general goals of the FreeBSD Project as a whole. Your method *may* work but it's by no means guaranteed, or even a major priority I'm afraid. Your method *may* work. But you can't *expect* it. We like many similar Projects have a wide variety of people involved (both developers and end-users) and an equally wide variety of "needs" those people have. On the one extreme we have developers who feel their hands are tied by not being able to make user-visible changes to stuff - they feel they could make the system better faster if they could change things in incompatible ways faster. On the other extreme we have people who hate change for reasons similar to what you are expressing here - it's a pain in the butt to need to change config files, it sucks if all the old executable files suddenly stop working, etc. So, there has been a long-standing compromise in place. For bumps in *minor* version numbers you can expect to be able to use your old config files, old executables continue to work, etc. This is, for example, moving from 7.2 to 7.3. However for bumps in *major* version numbers there can and likely will be changes made that cause exactly what you are seeing here. A 7.X kernel config file *might* work OK on 8.X but we do not guarantee that. If it does happen to work great, if not sorry. What you call "simply the next step" is a bump in minor version number. Depending on how active the developers have been and what they've focused on major version number bumps *can* qualify as what you call revolutionary. This general mode of operation has been in place for a very long time (it pre-dates my involvement on the Release Engineering Team). - -- Ken Smith - - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw1Oc0ACgkQ/G14VSmup/bEiQCfdtr8UkPp/QRcwUpGTlpRtJ2f RNsAn3+cV4jDuyQ38Wvm5eTiVObJ4DLy =4Bm7 -----END PGP SIGNATURE-----