[cgl_discussion] Re: [PATCH-RFC] README 1ST - New problem logging macros (2.5.38)
jgarzik at pobox.com
Mon Sep 23 22:28:27 PDT 2002
Greg KH wrote:
>>* Device Drivers use new macros to log "problems" when errors are
> Nice concept. But what's wrong with the existing method of logging when
> errors are detected? Can you give us some background as to what is
> lacking in the current stuff?
Bah, who needs define a problem when you have a sexy solution...
>>If event logging is configured....
>>* During the build process
>> the static details (textual description, problem attribute names,
>> format specifiers for problem attributes, source file name, function
>> name and line number) associated with the problem() and introduce()
>> calls are stored in a .log section in the .o file.
>>(3) 'make templates' extracts this data from the disk_dummy.o file and
>> generates a formatting template in templates/disk_dummy/disk_dummy.t:
>> facility "disk_dummy";
>> event_type 0x8ab218f4; /* file, message */
I don't see why we need a "make templates" at all in the kernel tarball.
This can be totally external to the kernel and still work fine.
>>(4) 'make templates_install' copies disk_dummy/disk_dummy.t to
If they are compiled into the kernel and modules, this is not needed in
the kernel tarball either.
It should be straightforward to [re-]generate templates on boot, much
like module dependencies are [re-]computed on boot when necessary.
>>For the following 3 invocations, the first 2 work, the 3rd does not...
>>problem(LOG_ALERT, "Disk on fire"); // OK
>>#define DISK_ON_FIRE "Disk on fire"
>>problem(LOG_ALERT, DISK_ON_FIRE); // OK
>>msg = "Disk on fire";
>>problem(LOG_ALERT, msg); // No good
> Why does this not work?
doh! I missed that. That "no good" example is in use in the kernel
today, implying that this new API reduces functionality...
More information about the cgl_discussion