lkml.org 
[lkml]   [2002]   [Sep]   [24]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateTue, 24 Sep 2002 01:28:27 -0400
FromJeff Garzik <>
SubjectRe: [PATCH-RFC] README 1ST - New problem logging macros (2.5.38)
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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:29    [W:0.182 / U:0.440 seconds]
©2003-2008 Jasper Spaans