Do you get me?
On 23/08/2023 14:35, Zhu Yanjun wrote:
On Wed, Aug 23, 2023 at 2:25 PM Zhijian Li (Fujitsu)I don't think it's a printk stuff.
<lizhijian@xxxxxxxxxxx> wrote:
Add PRINTK reviewers:
On 23/08/2023 14:12, Zhu Yanjun wrote:
在 2023/8/23 10:13, Li Zhijian 写道:Yeah, the message will be buffered until it is full or it meets a newline.
A newline help flushing message out.rxe_info_dev will finally call printk to output information.
In this link https://github.com/torvalds/linux/blob/master/Documentation/core-api/printk-basics.rst,
"
All printk() messages are printed to the kernel log buffer, which is a ring buffer exported to userspace through /dev/kmsg. The usual way to read it is using dmesg.
"
Do you mean that a new line will help the kernel log buffer flush message out?
Petr Mladek <pmladek@xxxxxxxx>
Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx>
Steven Rostedt <rostedt@xxxxxxxxxxx>
John Ogness <john.ogness@xxxxxxxxxxxxx>
This is about printk. They can decide this commit.
In general, when developers add some printk()/pr_info() to print some message in the kernel, they expect this message will be printed in time.
So most of the printk()/pr_info() calls in current kernel accompany a '\n' at the end.
And printk() will also print message to 'console' by default, console could be a serial port(ttyS0) or tty1 etc.
Thanks
Zhijian
Zhu Yanjun
Zhu Yanjun>
Signed-off-by: Li Zhijian <lizhijian@xxxxxxxxxxx>
---
drivers/infiniband/sw/rxe/rxe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/sw/rxe/rxe.c b/drivers/infiniband/sw/rxe/rxe.c
index 54c723a6edda..cb2c0d54aae1 100644
--- a/drivers/infiniband/sw/rxe/rxe.c
+++ b/drivers/infiniband/sw/rxe/rxe.c
@@ -161,7 +161,7 @@ void rxe_set_mtu(struct rxe_dev *rxe, unsigned int ndev_mtu)
port->attr.active_mtu = mtu;
port->mtu_cap = ib_mtu_enum_to_int(mtu);
- rxe_info_dev(rxe, "Set mtu to %d", port->mtu_cap);
+ rxe_info_dev(rxe, "Set mtu to %d\n", port->mtu_cap);
}
/* called by ifc layer to create new rxe device.