Re: Kernel messages...

Larry McVoy (
Wed, 13 May 1998 21:13:54 -0600

: Has anyone given any thought to the idea of pulling kernel messages out of
: the kernel binary itself, and using numerical referencing for them
: instead, in an attempt to see how much space would be preserved in the
: final kernel image?
: What I'm thinking of is possibly a module (which could be compiled into
: the kernel, of course) which handles the translation of numerical kernel
: messages to their string equivilents, with a hook in printk to handle the
: communication with that piece.

If I understand you correctly, the Sun/BSD xstr(1) may be what you want:


xstr - extract strings from C programs to implement shared

xstr -c filename [ -v ] [ -l array ]
xstr [ -l array ]
xstr filename [ -v ] [ -l array ]

xstr maintains a file called strings into which strings in
component parts of a large program are hashed. These
strings are replaced with references to this common area.
This serves to implement shared constant strings, which
are most useful if they are also read-only.

The command

xstr -c filename

extracts the strings from the C source in name, replacing
string references by expressions of the form &xstr[number]
for some number. An appropriate declaration of xstr is
prepended to the file. The resulting C text is placed in
the file x.c, to then be compiled. The strings from this
file are placed in the strings data base if they are not
there already. Repeated strings and strings which are
suffixes of existing strings do not cause changes to the
data base.

After all components of a large program have been com-
piled, a file declaring the common xstr space called xs.c
can be created by a command of the form


This xs.c file should then be compiled and loaded with the
rest of the program. If possible, the array can be made
read-only (shared) saving space and swap overhead.

xstr can also be used on a single file. A command

xstr filename

creates files x.c and xs.c as before, without using or
affecting any strings file in the same directory.

It may be useful to run xstr after the C preprocessor if
any macro definitions yield strings or if there is condi-
tional code which contains strings which may not, in fact,
be needed. xstr reads from the standard input when the
argument `-' is given. An appropriate command sequence
for running xstr after the C preprocessor is:

19 April 1989 1


cc -E name.c | xstr -c -
cc -c x.c
mv x.o name.o

xstr does not touch the file strings unless new items are
added; thus make(1) can avoid remaking xs.o unless truly

-c filename Take C source text from filename.

-v Verbose: display a progress report indicating
where new or duplicate strings were found.

-l array Specify the named array in program references
to abstracted strings. The default array name
is xstr.

strings data base of strings
x.c massaged C source
xs.c C source for definition of array
/tmp/xs* temp file when xstr filename doesn't
touch strings

make(1), mkstr(1)

If a string is a suffix of another string in the data
base, but the shorter string is seen first by xstr both
strings will be placed in the data base, when just placing
the longer one there would do.

19 April 1989 2

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to