Messages in this thread |  | | Date | Thu, 23 Jan 1997 14:04:17 -0500 | Subject | Fixing the printk's in drivers/block/*.c | From | (Dale R. Worley) |
| |
[This is the heading off a message I sent to Linus. The techniques for getting printk's into good shape might be of general interest.]
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."
|  |