1. #include "logf" should be #include "logf.h" in apps/debug_menu.c
2. lvl_codes should be "IANWEUC" instead of "IANIEUC" in
Also, it didn't patch cleanly against CVS but it was fixable.
Failed hunks: #1/5 in apps/logfdisp.c, #1/3 in firmware/logf.c
After fixing these, I checked functionality on my X5.
It neither crashed nor worked; i.e., .rockbox/syslog.log wasn't created and
even when I touch'ed it, it didn't fill with contents.
Note: using the 'dump logf' menu option did cause a HDD reaction.
[mailto:email@example.com] On Behalf Of Jonathan Gordon
Sent: Saturday, June 03, 2006 3:53 PM
To: Rockbox development
Subject: logf enhancements
last week i got the idea of getting logf used in the standard build in the
hope that it could be used to trace some of the painful bugs (i.e wierd
playback issues), so iv started work on making logf a bit nicer,,, so ive
attached a patch with the my work so far hopefully to get some feedback...
(i know we r in the freeze, but i rekon if this is used it might help speed
up the freeze....) stuff ive changed so far:
removed some ROCKBOX_HAS_LOGF defines (u should still define it if u want to
test out the patch coz it might not compile without that defined just yet)
added syslogf which is supposed to replace logf. the difference is syslog
allows a level for the log message.
the level is a combination of the subsystem (main thread, playback, etc),
and a error level warning, error, info, etc).
the idea with the levels is that errors with less severity then your choice
wont get logged, and even if the severity is higher than your level, it will
only get logged if its one of the sub-systems your monitoring..
so, all that is left to do is remove the rest of the ROCKBOX_HAS_LOGF
defines, add a nice log viewer and get the rest of rockbox using it...
so yeah... whatcha think?
Received on Sat Jun 3 21:33:15 2006