Date: Wed, 07 Jul 2010 22:37:01 -0400 From: Ken Smith <kensmith@buffalo.edu> To: "Mikhail T." <mi+thun@aldan.algebra.com> Cc: re@freebsd.org, tom@hur.st, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: 8.x grudges Message-ID: <4C3539CD.10204@buffalo.edu> In-Reply-To: <4C34E0E6.9070801@aldan.algebra.com> References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C3539CD.10204>