Re: what /boot/kernel/kernel output

On Sat, 24 Apr 2004, Stephen McKay wrote:

> [This is a resend.  My first attempt appears to have been eaten.  Sorry
> if this is the 2nd copy for you.]

I saw the first one later.

> For as long as I can remember, running the SCCS command "what" on the
> kernel of the day produced useful output: a single line fairly similar
> to "uname -v" but not quite so verbose.  It works up until FreeBSD 5.2.1
> (at least) but fails for current.
>
> It fails because a hack in the constructed file "vers.c" no longer
> works.  Here is a fix to the hack:
>
> --- newvers.sh.old     Wed Apr 14 13:01:18 2004
> +++ newvers.sh  Fri Apr 23 22:55:04 2004
> _at__at_ -85,7 +85,7 _at__at_
>  i=`make -V KERN_IDENT`
>  cat << EOF > vers.c
>  $COPYRIGHT
> -char sccspad[32 - 4 /* sizeof(sccs) */] = { '\\0' };
> +char sccspad[32 - 4 /* sizeof(sccs) */] = { '\\1' };
>  char sccs[4] = { '_at_', '(', '#', ')' };
>  char version[] = "${VERSION} #${v}: ${t}\\n    ${u}_at_${h}:${d}\\n";
>  char ostype[] = "${TYPE}";
>
> Without this, sccspad is put in the BSS.  I note that NetBSD solved
> this by duplicating the version string, one copy with _at_(#) and one
> without.  Perhaps this is better than second guessing the whims of
> the compiler.

Euww.  Almost anything is better.  Your change seems to be to work
around gcc now putting zero data in the bss.  I noticed the following
nearby bogusness:
- strings with local scope are not declared static.
- const strings are not declared const.
- initializer { '\\0' } has no effect.
- sccspad[] seems to be to work around gcc optimizing for space bloat
  by aligning long strings like the one in version[].
- the alignment for long strings is potentially very MD.  32 is for
  i386's.  I don't know if it works for other arches.
- the alignment of 32 is not even for i386's, since we use
  -mno-align-long-strings on i386's (unless CC is spelled "icc") to
  avoid the optimization.
- the alignment of 32 is not even not for i386's, since
  -mno-align-long-strings is broken.
- if the compiler is icc but CC is not spelled "icc", then we use the
  invalid option -mno-align-long-strings.
- if we are chummy with gcc then we can just use its alignment attribute
  to avoid the padding.

> Secondly, the output of "what" now has extraneous lines:
>
> $RCSfile: if_em_hw.h,v $$Revision: 1.37 $$Date: 2003/12/20 00:14:51 $
>
> which is printed twice.
>
> To solve this, we could #define NO_VERSION_CONTROL or simply delete
> the _at_(#) characters in line 45 in dev/em/if_em_hw.h.

This seems to be working (except it is a bug for headers to define data)
-- "what" shows you all 3 sccsids in the kernel :-).

> So, is this one tradition that still exists, or does this go in my
> growing collection of personal hacks?  Should I patch either or both
> of these?  The quick hack or the NetBSD way?

Use the NetBSD fix, and negotiate the fix for em with its maintainer.

Bruce