Re: [PATCH] net/slirp: Use newer slirp_*_hostxfwd API

[Samuel Thibault <samuel.thibault@gnu.org>]

Samuel Thibault, le dim. 28 avril 2024 19:23:03 +0200, a ecrit:
> Thomas Weißschuh, le jeu. 22 févr. 2024 11:44:13 +0100, a ecrit:
> > On Tue, Mar 22, 2022 at 06:58:36PM -0700, Nicholas Ngai wrote:
> > > Pinging this. It’s a bit old, though the patch still applies cleanly to
> > > master as far as I can tell.
> > > 
> > > Link to patchew is
> > > https://patchew.org/QEMU/20210925214820.18078-1-nicholas@ngai.me/.
> > > 
> > > I’d love to get https://gitlab.com/qemu-project/qemu/-/issues/347 addressed
> > > once libslirp makes a release with added Unix-to-TCP support in the hostxfwd
> > > API, but this patch is a requirement for that first.
> > 
> > I'm also interested in this PATCH and a resolution to issue 347.
> > 
> > FYI your patch triggers checkpatch warnings, see [0].
> 
> Indeed, the code should be fixed to use qemu_strtoi, like already done
> elsewhere in net/slirp.c
> 
> > Maybe you can resend the patch with the review tags and the checkpatch
> > warnings cleaned up.
> > 
> > Also it would be useful to know how the patch changes the version
> > requirements of the libslirp dependency.
> > (The version requirement should also be enforced in meson.build)
> > Also the commit in subprojects/slirp.wrap should be high enough,
> > which seems to already be the case however.
> > 
> > It seems it requires libslirp 4.6.0 from 2021-06-14, which is only
> > available from Debian 12 or Ubuntu 22.04 and no release of RHEL.
> 
> The code can easily be made optional with SLIRP_CHECK_VERSION(4,5,0)
> 
> (the hostxfwd interface was added in 4.5.0, not 4.6.0 ; the unix socket
> part was added in 4.7.0)

I went ahead and just fixed the code, by sticking more to the original
code, and use a #if between the hostxfwd and hostfwd APIs. I sent the
corresponding pull request for inclusion.

Nicholas, you'll be able to rebase your unix work on top of it. Be sure
however to update the documentation of the options, we won't commit it
unless it is documented (hint: anything that is not documented does
*not* exist for users)

There's also the IPv6 support which some people were having a look at,
and which'd need to be revived...

Samuel