Re: [PATCH-RFC] README 1ST - New problem logging macros (2.5.38)

[Jeff Garzik]

Greg KH wrote:
>>The concept:
>>-----------
>>* Device Drivers use new macros to log "problems" when errors are
>>  detected.
> 
> 
> 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...
</sarcasm>

>>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. 
> 
> 
> Nice.

indeed

>>(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 
>>     /var/evlog/templates.  

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.

>>Notes:
>>-----
>>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...

	Jeff