Date: Thu, 19 May 2005 16:52:33 -0700 From: Colin Percival <cperciva@freebsd.org> To: freebsd-arch@freebsd.org Subject: RFC: Using fixed-length strings for version[] and osrelease[] Message-ID: <428D26C1.2020201@freebsd.org>
next in thread | raw e-mail | index | archive | help
In vers.c (created by src/sys/conf/newvers.sh), the strings version[] and osrelease[] are not declared with a fixed length. As a result, as the kernel moves from x.y-RELEASE to x.y-RELEASE-p1, and later to x.y-RELEASE-p10, the length of these strings will change; this causes cascading differences in addresses throughout the kernel binary. This is not a major problem for most people, but it causes difficulty for FreeBSD Update. Such cascading differences in addresses cause FreeBSD Update to recognize the kernel as having changed, at which point it decided that the new kernel needs to be distributed to everybody -- or rather, it would do this but for the fact that my FreeBSD Update build code replaces the traditional "x.y-RELEASE-p15" name with "x.y-SECURITY". As this is the last remaining place where the files built and distributed by FreeBSD Update differ from the standard src tree, I'd like to remove the need for this local patch. At BSDCan last week, Jacques Vidrine pointed out that this could be done simply by declaring these two strings as having fixed length -- i.e., by zero-padding them. Would anyone object to the following patch being applied? --- newvers.sh 15 Jan 2005 13:25:41 -0000 1.68 +++ newvers.sh 19 May 2005 23:48:21 -0000 @@ -87,9 +87,9 @@ cat << EOF > vers.c $COPYRIGHT char sccspad[32 - 4 /* sizeof(sccs) */] = { '\\0' }; char sccs[4] = { '@', '(', '#', ')' }; -char version[] = "${VERSION} #${v}: ${t}\\n ${u}@${h}:${d}\\n"; +char version[512] = "${VERSION} #${v}: ${t}\\n ${u}@${h}:${d}\\n"; char ostype[] = "${TYPE}"; -char osrelease[] = "${RELEASE}"; +char osrelease[64] = "${RELEASE}"; int osreldate = ${RELDATE}; char kern_ident[] = "${i}"; EOF The lengths 512 and 64 are chosen as being considerably more than double the likely lengths of these strings; on my system, these two strings are 12 bytes and 134 bytes long respectively. Colin Percival
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?428D26C1.2020201>