在嵌入式系统上将内核控制台发送到哪里？
我正在开发一个嵌入式系统，该系统当前通过串行端口 1 上的控制台输出启动 Linux（使用启动加载程序中的控制台启动参数）。 然而，最终我们将使用这个串行端口。 内核控制台输出的最佳解决方案是什么？ /dev/null？ 能否以某种方式将其放在 pty 上以便我们可以访问它？
I'm developing an embedded system which currently boots linux with console output on serial port 1 (using the console boot param from the boot loader). However, eventually we will be using this serial port. What is the best solution for the kernel console output? /dev/null? Can it be put on a pty somehow so that we could potentially get access to it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以使用 dmesg 从 shell 访问 printk 消息缓冲区。 内核缓冲区的大小有限，并且会用最新的条目覆盖最旧的条目，因此您需要定期检查 dmesg 或按照 @bmdhacks 的建议连接 netconsole。
如果没有控制台，您将错过内核崩溃打印出的任何 oops 信息。 如果在 TCP 设法将输出传递到远程套接字之前内核死机并开始重新启动，那么即使使用 netconsole 也可能无济于事。 我们通常修改kernel/panic.c:panic()，将寄存器内容和其他状态保存到NOR flash的一个区域，这样至少会有一些信息可用于事后调试。
You can access the printk message buffer from a shell using dmesg. The kernel buffer is of finite size and will overwrite the oldest entries with the most recent, so you'd need to either check dmesg periodically or hook up netconsole as @bmdhacks suggests.
If there is no console you'll miss any oops information printed out by a kernel crash. Even using netconsole may not help there, if the kernel dies and begins to reboot before TCP manages to deliver the output to the remote socket. We generally modify kernel/panic.c:panic() to save register contents and other state to an area of NOR flash, so there will be at least some information available for post-mortem debugging.
如果您只想从控制台读取内核 printk 消息，而不是实际运行 getty 或 shell，则可以使用 netconsole。 您可以向引导加载程序内核选项（或 modprobe netconsole）提供以下内容：
其中 4444 是本地端口，10.0.0.1 是本地 IP，eth1 是发送消息的本地接口。 9353 是远程端口，10.0.0.2 是要将消息发送到的远程 IP，最后一个参数是您的远程（例如：您的桌面）系统的 MAC 地址。
然后要查看运行的消息：
您可以在 Documentation/networking/ 中阅读有关此内容的更多信息netconsole.txt
If you just want to read kernel printk messages from the console, and not actually run getty or a shell on it, you can use netconsole. You can supply the following to your bootloader kernel options (or to modprobe netconsole):
where 4444 is the local port, 10.0.0.1 is the local ip, eth1 is the local interface to send the messages out of. 9353 is the remote port, 10.0.0.2 is the remote ip to send the messages to, and the final argument is your remote (eg: your desktop) system's mac address.
Then to view the messages run:
You can read more about this in Documentation/networking/netconsole.txt