Re: [PATCH v4 2/4] util/qemu-sockets.c: Split host:port parsing out of inet_parse

[Samuel Thibault]

Samuel Thibault, le lun. 01 mars 2021 17:27:47 +0100, a ecrit:
> Doug Evans, le lun. 01 mars 2021 08:23:03 -0800, a ecrit:
> > On Sun, Feb 28, 2021 at 1:40 PM Samuel Thibault <[1]samuel.thibault@gnu.org>
> > wrote:
> > 
> >     [...]
> >     > Note that one issue I am leaving for later (i.e., I don't want to drag
> >     this
> >     > patch series out to include it), is whether and how to support
> >     ipv4-host->
> >     > ipv6-guest forwarding and vice versa. Can libslirp support this?
> > 
> >     That would be feasible yes: since the data flow is completely rebuilt
> >     between the host and the guest, there is no remnant of the IP version.
> >     It was simpler to have e.g. udp_listen and udp6_listen separate to keep
> >     uint32_t / in6_addr parameters, but there is no strict reason for this:
> >     the haddr is only passed to the bind() call, and the laddr is only
> >     recorded in the so. Put another way, a refactoring patch could be to
> >     just hand udp_listen two sockaddrs, and it will just work fine. We'd
> >     then introduce a slirp_add_hostfwd that takes two sockaddr instead of
> >     host/port.
> > 
> > 
> > 
> > I guess I'm not familiar enough with this code.
> > Help me understand how passing two addresses to udp_listen is simpler.
> > That feels confusing from an API viewpoint.
> 
> ? udp_listen already takes two addresses + two ports. I just mean
> replacing that with two sockaddr, which contains both, but also contains
> the address family. I submitted this to 
> 
> https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/74

And the public API to 
https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/75

Ideally we'd then just drop the ipv6-only public API.

Samuel