> 2025年2月25日 21:29，Marc-André Lureau <marcandre.lur...@gmail.com> 写道： > > Hi Haoqian > > On Tue, Feb 25, 2025 at 5:19 PM Haoqian He <haoqian...@smartx.com> wrote: >> >> I use chardev to connect with a vhost-user target, the chardev backend type >> is >> socket, part of QEMU boot parameter: >> -device vhost-user-blk-pci,chardev=my-vhost-blk-0,id=my-vhost-blk-0,\ >> bus=pci.1,addr=0x1,bootindex=1,num-queues=4 \ >> -chardev socket,id=my-vhost-blk-0,path=/tmp/vhost-blk.1 >> >> I want to log the chardev’s socket path when socket successfully connected >> in tcp_chr_connect (chr->filename), but i got "unix:" instead of the expected >> "unix:/tmp/vhost-blk.1". >> >> The chr->filename was computed from the function qemu_chr_compute_filename, >> which always return the unix path store by local QIOChannelSocket localAddr. >> >> Unfortunately, the localAddr is obtained via getsockname (see the function >> qio_channel_socket_set_fd), and according to the man page: >> "getsockname() returns the current address bound by the socket sockfd". >> >> In this scenario, the socket client's sockfd is unbonded, so the socket >> filename in localAddr(ss) is NULL. >> As a solution, we can use remoteAddr(ps) obtained by getpeername (see the >> function qio_channel_socket_set_fd). >> > > thanks a lot, I didn't notice ps != ss in the patch. That makes sense. > > Reviewed-by: Marc-André Lureau <marcandre.lur...@redhat.com> > > > > -- > Marc-André Lureau
Thanks, Lureau. -- Haoqian
