Messages in this thread | | | Date | Tue, 10 Feb 2004 11:22:59 +0100 | From | wdebruij@dds ... | Subject | missing vprintf in kernel.api. Interest in patch? |
| |
Hi,
while writing a new kernel module I needed vprintf behaviour to send additional info to printk (e.g. __LINE__ and __FUNCTION__ preprocessor macros). While the kernel API contains vsnprintf and vsprintf functions, it does not contain a vprintf and since we have no access to the printk_buf structure it is therefore impossible to directly write a formatted argument using a va_list to the log.
As a quick fix I wrote my own function using vsnprintf and printk, but this is far from ideal when more people need such functionality.
Indeed, doing a quick grep on the (2.6.1) tree I noticed that I am not the only one creating my own vprintf. In arch/um/kernel/tt/tracer.c, drivers/acpi/osl.c and drivers/acpi/utilities/utdebug.c others have also written similar functions. Not to mention all the DPRINTF, YYDPRINTF, etc. macros declared everywhere
Therefore my question is this: is there any interest in
(1) a small patch that extracts the vsnprintf(printk_buf,...) from printk and thus creates a vprintf function (trivial change, perhaps +5 lines of code). and/or (2) a kernel wide DPRINTK (or something) macro that adds the __FILE__, __FUNCTION__ and __LINE__ macros to the output. and/or (3) an extension of 2 that also prints out clockcycles or timing statistics.
IMHO, everyone debugging and optimizing his code needs these features. It might help clean up the codebase if everyone uses the same helper functions. And since I already have such code laying around, sending in a patch is a trivial task right now.
Please share your views, I don't want to create a patch if it'll be rejected instantaneously because of some unspoken rule I haven't heard of.
cheers,
Willem de Bruijn
- 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/
| |