模块调用之间有很多层 printk(...) 并且输出显示在控制台上。
printk(...)
我对printk()的理解是保证在下一行代码运行之前立即输出到控制台,而不是将其输出放在最终在某个时刻刷新的缓冲区。它是否正确?
不,这不正确。没有“控制台” printk() 实施,不应该有任何。总有一个缓冲区,多层缓冲区。这条线 1705年在printk.c 回答你的问题。该 printk_emit() function使用静态分配的缓冲区 static char textbuf[LOG_LINE_MAX]; 和电话 vscnprintf(textbuf, sizeof(textbuf), ...) 在它上解析参数。所以它使用缓冲区。我认为不可能写一个 printf 没有使用内部缓冲区的功能,至少它更难。而且 __log_buf 变量是静态分配的缓冲区,字符数组和它 是 内核日志缓冲区。
printk()
printk_emit()
static char textbuf[LOG_LINE_MAX];
vscnprintf(textbuf, sizeof(textbuf), ...)
printf
__log_buf
printk被发送到控制台的时间和它在dmesg中显示的时间之间是否有滞后,这会让我的系统在看到输出之前冻结?
是?总是存在滞后。我不知道如何定义一个“滞后”(一个毫秒?一秒?一纳秒?)但背后的装配说明 printk 函数必须执行,然后是所有层,直到它们被放入 __log_buf 静态变量。然后 dmesg 等待着 read() 系统调用被唤醒我想在里面的某个地方 console_unlock 。醒来之后 dmesg 最后会打电话 devkmsg_read() 将返回缓冲区的函数。然后 dmesg() 将会通知 write() 收到数据后,在stdout上进行系统调用。然后 write() kernel syscall会尝试在屏幕上写一些东西 - 所以数据必须一直通过控制台驱动程序和显示驱动程序和图形驱动程序。总是存在滞后。但它应该是最小的。
printk
dmesg
read()
dmesg()
write()
dmesg在修复有问题的代码行后显示有问题的printks
这就是说 dmesg 没有得到内核日志的输出。可能还有其他事情发生。最简单的是 dmesg 进程没有得到cpu时间,在读取syslog时被阻塞,你的模块在内部执行irq disabled,依此类推。