如何在linux内核空间中读取环形缓冲区？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/9533708/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to read ring buffer within linux kernel space?
提问by Yingyi Xu
I'm writing a Linux character driver which can print system logs in user space. Just as the command 'dmesg' does. I've learned that all the log that we print with 'printk' will be sent to a space named ring buffer. So I have the questions:
我正在编写一个 Linux 字符驱动程序，它可以在用户空间打印系统日志。就像命令 'dmesg' 所做的那样。我了解到我们使用“printk”打印的所有日志都将发送到名为环形缓冲区的空间。所以我有以下问题：
- Is ring buffer inside kernel space?
- If so, how can I read the ring buffer inside kernel space? (I've tried to read the source code of dmesg.c. But it did not help.)
- 内核空间内是否有环形缓冲区？
- 如果是这样，我如何读取内核空间内的环形缓冲区？（我试图阅读 dmesg.c 的源代码。但它没有帮助。）
采纳答案by Pavan Manjunath
What you are looking for is /proc/kmsg. This is the kernel ring buffer!
您正在寻找的是/proc/kmsg. 这是内核环形缓冲区！
Yes, this is inside kernel space. Any process trying to read it should have super user privileges to read it!
How to read it the ring buffer? Here is a beautiful illustration from IBM Developerworks
是的，这是在内核空间内。任何试图读取它的进程都应该具有读取它的超级用户权限！
如何读取它的环形缓冲区？这是来自 IBM Developerworks 的精美插图
dmesgwould be your first resort! How does dmesgaccomplish its task? By a call to syslog()! How does syslogdo its job? Through the system call interface which in turn call do_syslog(). do_syslog()does the finishing act like this.
dmesg将是您的首选！dmesg如何完成它的任务？通过调用syslog()! syslog是如何工作的？通过系统调用接口依次调用do_syslog()。do_syslog()收尾是这样的吗。
Here are a few more resources to get you more info about /proc/kmsgand kernel logging in general-
这里有更多资源可以为您提供有关/proc/kmsg内核日志记录的更多信息 -
回答by Peter Teoh
This is further to Pavan's very good answer (taught me a lot):
这是对 Pavan 非常好的答案的进一步补充（教会了我很多）：
Different distro may redirect the output of /proc/kmsg to any physical log files or virtual devices (/dev/xxx) they like. But "/proc/kmsg" is the original source of the kernel log, because the kernel implement its ring buffer operation inside fs/proc/kmsg.c:
不同的发行版可能会将 /proc/kmsg 的输出重定向到他们喜欢的任何物理日志文件或虚拟设备 (/dev/xxx)。但是“/proc/kmsg”是内核日志的原始来源，因为内核在fs/proc/kmsg.c里面实现了它的环形缓冲区操作：
static const struct file_operations proc_kmsg_operations = {
.read = kmsg_read,
.poll = kmsg_poll,
.open = kmsg_open,
.release = kmsg_release,
.llseek = generic_file_llseek,
};
So how you see the output is this:
所以你如何看到输出是这样的：
sudo tail -f /proc/kmsg
须藤尾 -f /proc/kmsg
But you can only see all the messages generated AFTER you have issued this command - all previous messages in the ring buffer will not be printed out. And so to see the physical file output, you can search for the user of "/proc/kmsg":
但是您只能看到在您发出此命令后生成的所有消息 - 环形缓冲区中的所有先前消息都不会被打印出来。所以要查看物理文件输出，可以搜索“/proc/kmsg”的用户：
sudo lsof |grep proc.kmsg
须藤 lsof |grep proc.kmsg
And my machine indicated this:
我的机器指示了这一点：
rsyslogd 1743 syslog 3r REG 0,3 0 4026532041 /proc/kmsg
in:imuxso 1743 1755 syslog 3r REG 0,3 0 4026532041 /proc/kmsg
in:imklog 1743 1756 syslog 3r REG 0,3 0 4026532041 /proc/kmsg
rs:main 1743 1757 syslog 3r REG 0,3 0 4026532041 /proc/kmsg
So now it is pid 1743, let's see the files fd opened by 1743:
所以现在是pid 1743，我们看看1743打开的文件fd：
sudo ls -al /proc/1743/fd
须藤 ls -al /proc/1743/fd
lrwx------ 1 root root 64 Dec 11 08:36 0 -> socket:[14472]
l-wx------ 1 root root 64 Dec 11 08:36 1 -> /var/log/syslog
l-wx------ 1 root root 64 Dec 11 08:36 2 -> /var/log/kern.log
lr-x------ 1 root root 64 Dec 11 08:36 3 -> /proc/kmsg
l-wx------ 1 root root 64 Dec 11 08:36 4 -> /var/log/auth.log
And so there you go, pid 1743 is rsyslogd, and it redirect the output of /proc/kmsg to files like /var/log/syslog and /var/log/kern.log etc.
就这样，pid 1743 是 rsyslogd，它将 /proc/kmsg 的输出重定向到 /var/log/syslog 和 /var/log/kern.log 等文件。
