On Thursday 17 September 2009, Miguel Aguilar wrote: > I have another question: When should I use dev_err and dev_dbg in a probe > function, for reporting the errors (-ENOMEM, -ENODEV, -ENOMEM, etc)? My two cents: dev_dbg() for configuration errors, which vanish once the board config is properly set up and are only needed in early debug stages. For anything else (rare!) it's OK to use dev_err(). Some folk like to clutter kernel images with gobs of strings for messages that never appear. I'm not one of them; and I think drivers should be written to minimize space used on production systems. Save that RAM for Real Work (tm)! It's a good habit to scan the driver object before you call work on it "done". For platform drivers, probe/remove code should normally sit in init/exit sections. Symbols should as a rule not be exported from drivers. Having more than a handful of strings should raise red flags ... who is ever going to read them? (And why, and what should they do with them once they've seen those messages?) Real hardware faults generally deserve log messages. Little else does. Even look at the object code generated ... you may well observe stupidly large amounts of code generated for some things, which can easily be trimmed. (Remember that the cost of a few extra fetches into I-cache often dwarf call/return costs for a few helper subroutines, even on critical paths!) Sometimes a few minutes spent with such basic checks can show problems that bloat the runtime footprint by 20% or more. (Less after you get good habits though!) - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
