A better way than printk() to leave a kernel module log?

Question

I am usingprintk() to leave a log message of a kernel module. I've modified ath9k_htc WLAN card module to leave a log message whenever a WLAN card transmits or receives a data or an acknowledgement frame. A log meesage contains a frame type and clock cycles.

printk(KERN_DEBUG "MyModule: DATA at %llu\n", get_ccnt());

where get_ccnt() is:

static __inline__ long long int get_ccnt(void)
{
#if defined(__i386__)
    long long int x;
    __asm__ volatile (".byte 0x0f, 0x31" : "=A" (x));
    return x;

#elif defined(__x86_64__)
    unsigned int hi, lo;
    __asm__ __volatile__ ("rdtsc" : "=a"(lo), "=d"(hi));
    return ( (long long int)lo)|( ((long long int)hi)<<32 );

#endif
}

What I concern is, frames are transmitted and received very frequently. But I think printk() cannot be executed and finished as fast as frames are transmitted and received.

Before I decided to use prinkt(), I have though about using message queue or signal. But, I've given up using them because they are not easy to use in a kernel module or I have little knowledge about it.

(Yes, I want to pass a frame type and clock cycles from a kernel module to a userspace app. As I am using printk(), I read a log message with the following:)

FILE *fp = popen("dmesg | grep MyModule");
char linebuff[512];
while (fgets(linebuff, 512, fp) != NULL) {
    do_something();
}

So, is it not good to use printk() to pass a message from a kernel module to a userspace app when a messagecontains time-critical data?

One trivial question is, calling get_ccnt() function makes measurements of clock cycles inaccurate? I don't think so because it is an __inline__ function...

Answer 1

It's not completely clear what you're trying to do, but the fact that you want to write code to run dmesg and grep its contents implies that this is not just for debugging. In that case, printk is not the right solution. You should use the device interface to pass information from your module to user-space. That's what it's for. Then your user-space code can just open /dev/mydevice and read data from it.

printk is for debugging and diagnostics, not for ordinary communication between kernel- and user-space. You will totally overwhelm the printk buffer if there is any significant amount of network traffic.

Use of the timestamp counter is fine for debugging, but is generally ill-suited for stable long-term time measurements (among others, processor frequencies vary, and multiple processors might not be synchronized). You're better off using ktime_get or do_gettimeofday or one of the other kernel time interfaces.