Here are patches to get all the printk's in the drivers/block
directory into good shape -- that is, each one starts with a KERN_*
level symbol, and each one prints exactly one line. The first rule is
needed to ensure that the reporting of messages is not at the whim of
the default level, which has changed in the past, messing up my syslog
logging. The second rule is needed to ensure that messages are listed
in the log as they are intended by the code, since if a line is
printed in sections, other processes can (and do) issue log messages
in between the sections.
These changes were originally made against 2.0.23, and compiled and
ran in that environment. (And I notice that some of the above
problems were fixed under the modified kernel.) These patches are
revised to work against 2.1.21. (The patches 2.0.23 are about twice
as large as the patches against 2.1.21, so the developers are cleaning
up the code.) I haven't run the 2.1.21 changes, but they compile
cleanly in a kernel with *everything* configured in.
The single exception to the above rules is the output of the rotator
during loading of the ramdisk in rd_load_image in drivers/block/rd.c,
but that shouldn't be a practical problem, as that is during kernel
initialization, and nothing else is running then.
For most printk's, all I needed to do was add a KERN_* symbol at the
beginning. I guessed what level would be appropriate from the
contents of the printk or the context. The most common messages were
device initialization messages (which got KERN_INFO) and obvious error
messages (KERN_ERR). Some that claimed to be "warnings" got
KERN_WARNING, and a few seemed suitable for KERN_NOTICE. Anything
conditionalized with "#ifdef DEBUG" or "#if 0" I gave KERN_DEBUG.
Quite a number of printk's did not have ending newlines. In some
cases, this seemed to be an ordinary mistake (usually because the flow
of control did not ensure that a newline would be printed in the near
future), and I inserted one. In many cases, though, the message was
being output a section at a time. In these cases, I declared an
automatic buffer of 100 or 200 characters ("buffer") and an integer to
record how many characters were in it ("bufptr") and used sprintf() to
compose the message in the buffer. (I sure hope the kernel sprintf
returns the number of characters output, like the standard says!) I
then used printk to output the message. Things only got messy in
genhd.c, where I had to add arguments to ide_xlate_1024 to carry
buffer and bufptr into the function from its callers.
In some cases, I split lines to keep the line length less than 80
characters, or inserted spaces after commas in parameter lists, so
they would be more legible.
Dale
-- Dale R. Worley Ariadne Internet Services Voice: +1 617-899-7949 Fax: +1 617-899-7946 E-mail: worley@ariadne.com "Internet-based electronic commerce solutions to real business problems."