d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Allow newer config versions to config older versions with the same

Browse Source 
major number.

Reviewed by: ru@, jhb@, arch@ (a few months ago)

# this is subject to refinement based on experience.
This commit is contained in:
Warner Losh 2006-02-03 06:12:10 +00:00
parent 6d7c1bdccd
commit d5e0beb486
2 changed files with 30 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
usr.sbin/config/configvers.h
View File

@ -1,7 +1,15 @@
/*-
* This file is in the public domain
*
* $FreeBSD$
*/
/*
* 6 digits of version. The most significant are branch indicators
* (eg: RELENG_2_2 = 22, -current presently = 70 etc). The least
* significant digits are incremented as needed.
* 6 digits of version. The most significant are branch indicators at the
* time when the last incompatible change was made (which is why it is
* presently 6 on 7-current). The least significant digits are incremented
* as described below. The format is similar to the __FreeBSD_version, but
* not tied to it.
*
* DO NOT CASUALLY BUMP THIS NUMBER! The rules are not the same as shared
* libs or param.h/osreldate.
@ -21,25 +29,25 @@
* compatable with the new buildkernel. The buildtools phase and much more
* comprehensive error code returns solved this original problem.
*
* Most end-users will use buildkenel and the build tools from buildworld.
* Most end-users will use buildkernel and the build tools from buildworld.
* The people that are inconvenienced by gratuitous bumps are developers
* who run config by hand.
* who run config by hand. However, developers shouldn't gratuitously be
* inconvenienced.
*
* One should bump the CONFIGVERS in the following ways:
*
* (1) If you change config such that it won't read old config files,
* then bump the major number. You shouldn't be doing this unless
* you are overhauling config. Do not casually bump this number
* and by implication do not make changes that would force a bump
* of this number casually. You should limit major bumps to once
* per branch.
* (2) For each new feature added, bump the minor version of this file.
* When a new feature is actually used by the build system, update the
* %VERSREQ field in the Makefile.$ARCH of all the affected makefiles
* (typically all of them).
*
* $FreeBSD$
*/
#define CONFIGVERS 600004
/*
* Examples of when there should NOT be a bump:
* - Adding a new keyword
* - Changing the syntax of a keyword such that old syntax will break config.
* - Changing the syntax of a keyword such that new syntax will break old
* config binaries.
*
* Examples of when there should be a bump:
* - When files generated in sys/$mach/compile/NAME are changed and the
* Makefile.$mach rules might not handle it correctly.
* - When there are incompatable changes to the way sys/conf/files.* or the
* other associated files are parsed such that they will be interpreted
* incorrectly rather than fail outright.
*/
#define MAJOR_VERS(x) ((x) / 100000)

3
usr.sbin/config/mkmakefile.c
View File

@ -153,7 +153,8 @@ makefile(void)
do_clean(ofp);
else if (strncmp(line, "%VERSREQ=", sizeof("%VERSREQ=") - 1) == 0) {
versreq = atoi(line + sizeof("%VERSREQ=") - 1);
if (versreq != CONFIGVERS) {
if (MAJOR_VERS(versreq) != MAJOR_VERS(CONFIGVERS) ||
versreq > CONFIGVERS) {
fprintf(stderr, "ERROR: version of config(8) does not match kernel!\n");
fprintf(stderr, "config version = %d, ", CONFIGVERS);
fprintf(stderr, "version required = %d\n\n", versreq);