In the early driver development, printk very helpful in debugging and testing new code. When you drive an official release, in other words, you should get rid of, or at least close, the print statement. Unfortunately, you're likely to find, just when you think you no longer need these messages and remove them when you want to implement a new feature in the drive (or someone finds a bug), then at least you want to open a message. there are several ways to solve this 2 question, globally turned on or off debug messages and you open or close a single message.
Here we demonstrate a method of encoding printk calls, you can individually or globally open or close them; this technique relies on the definition of a macro, it changes when you want to use it as a printk (or printf) call.
- Each printk statement can be opened or closed by removal Hinako macro definition to a single character or added.
- All messages can be immediately turned off, by changing the value of the CFLAGS variable before compiling.
- The same can be used in a print statement kernel code and user-level code, especially so for the message, drivers and test procedure can be managed in the same way.
The following code fragment implements these features directly from the header file scull.h:
#undef PDEBUG /* undef it, just in case */
#ifdef SCULL_DEBUG
# ifdef KERNEL
/* This one if debugging is on, and kernel space */
# define PDEBUG(fmt, args...) printk( KERN_DEBUG "scull: " fmt, ## args)
# else
/* This one for user space */
# define PDEBUG(fmt, args...) fprintf(stderr, fmt, ## args)
# endif
#else
# define PDEBUG(fmt, args...) /* not debugging: nothing */
#endif
#undef PDEBUGG #define PDEBUGG(fmt, args...) /* nothing: it's a placeholder */
Symbols and definitions to define PDEBUG, depending on whether SCULL_DEBUG defined above, and the manner in which message display environment for code running: when it is used to call the kernel printk kernel, use libc call fprintf to standard error running in user space . PDEBUGG symbol, in other words, what is not; he used to easily "comment" print statements without completely get rid of them.
To further simplify the process, add the following lines to your makfile in:
# Comment/uncomment the following line to disable/enable debugging DEBUG = y
# Add your debugging flag (or not) to CFLAGS ifeq ($(DEBUG),y)
DEBFLAGS = -O -g -DSCULL_DEBUG # "-O" is needed to expand inlines else
DEBFLAGS = -O2
endif
CFLAGS += $(DEBFLAGS)
Macros defined in this section appearing in dependence gcc preprocessor extensions to ANSI C and supports macros with a variable number of arguments. This gcc dependency should not be a problem, because in any case the core is dependent on the inherent characteristics gcc Further , makefile relies GNU version of make; once again, the kernel is also dependent on GNU make, so this dependency is not a problem.
If you are familiar with C preprocessor, you can extend the concept of the definition given to implement a "debug" a different definition level, arrange an integer (or bit mask) value to each level, in order to decide how it should be detailed.
But each drive has its own features and monitoring needs good programming skills is to choose the best balance between flexibility and efficiency, we can not tell you what is best. Remember, the preprocessor condition (along with constant expression code) executed at compile time, so you must recompile to turn on or change the message. One possible option is to use C conditionals, it is executed at runtime, thus, it allows you to open or in the event of execution change the message mechanism. this is a nice feature, but it requires additional processing each time the code is executed, so that even if the message is to shut down will affect the efficiency. sometimes this unacceptable loss of efficiency.
Macro definition in this section appears in many cases have proven to be useful, the only drawback is the requirement to recompile the message after any change to it.