Alexander Smirnov wrote:
> I think it's not a good idea to put debuging control flag outside from
> the driver code.
> It will be better to add internal debug level or flag by using macro.
> There are lots and
> lots of examples in kernel drivers, just grep for "DEBUG" word.

Both concept exists in the kernel - some keep their debug flags local
(so you need to edit the source to enable debugging) while others put
them into a config option (making it easier to set/unset and avoiding
conflicts when pulling/pushing changes (*), but at the cost of adding
yet another option).

You can find the latter with  grep DEBUG .config

They're usually for entire subsystems, not for individual drivers.
That's why I grouped them as well.

(*) E.g., a pull fails because you have a conflicting local change
    (the debug flag). Or before committing some change, you have to
    remember to revert the debug flag. If you forget, you turn it on
    for everyone else. Makes for a bumpy workflow.

Anyway, I don't particularly care about how it's done, just as long
as there's an easy way to silence the flood of debug output :-)

- Werner

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

Reply via email to