On Wed, Feb 10, 2021 at 8:49 AM Daniel P. Berrangé <berra...@redhat.com> wrote:
> On Wed, Feb 10, 2021 at 08:31:40AM -0800, Doug Evans wrote: > > On Wed, Feb 10, 2021 at 1:31 AM Daniel P. Berrangé <berra...@redhat.com> > > wrote: > > > > > On Tue, Feb 09, 2021 at 06:16:57PM -0800, Doug Evans wrote: > > > > On Thu, Feb 4, 2021 at 10:25 AM Doug Evans <d...@google.com> wrote: > > > > > > > > > On Thu, Feb 4, 2021 at 2:03 AM Daniel P. Berrangé < > berra...@redhat.com > > > > > > > > > wrote: > > > > > > > > > >> On Wed, Feb 03, 2021 at 03:35:36PM -0800, dje--- via wrote: > > > > >> > Add support for ipv6 host forwarding > > > > >> > > > > > >> > This patchset takes the original patch from Maxim, > > > > >> > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg569573.html > > > > >> > and updates it. > > > > >> > > > > > >> > New option: -ipv6-hostfwd > > > > >> > > > > > >> > New commands: ipv6_hostfwd_add, ipv6_hostfwd_remove > > > > >> > > > > > >> > These are the ipv6 equivalents of their ipv4 counterparts. > > > > >> > > > > >> Before I noticed this v3, I send a reply to your v2 sugesting > > > > >> that we don't need to add any new commands/options. We can > > > > >> use existing inet_parse() helper function to parse the address > > > > >> info and transparently support IPv4/6 in the existing commands > > > > >> and options. This matches normal practice elsewhere in QEMU > > > > >> for IP dual stack. > > > > >> > > > > > > > > > > I'm all for this, fwiw. > > > > > > > > > > > > > > > > > I should say I'm all for not adding new commands/options. > > > > Looking at inet_parse() it cannot be used as-is. > > > > The question then becomes: Will refactoring it buy enough? > > > > > > What's the problem your hitting with inet_parse ? > > > > > > > > > First, this is the inet_parse() function we're talking about, right? > > > > int inet_parse(InetSocketAddress *addr, const char *str, Error **errp) > > > > > https://gitlab.com/qemu-project/qemu/-/blob/master/util/qemu-sockets.c#L618 > > Yes, that's right. > Thanks, just wanted to be sure. The syntax it supports is not the same as what's needed for host forwarding. inet_parse: address:port,option1,option2 (where options are to=,ipv4,etc). hostfwd: address:port-address:port If we wanted to have a utility that parsed "address:port" for v4+v6 then we'd have to split the "address:port" part out of inet_parse. Plus the way inet_parse() parses the address, which is fine for its purposes, is with sscanf. Alas the terminating character is not the same (',' vs '-'). IWBN to retain passing sscanf a constant format string so that the compiler can catch various errors, and if one keeps that then any kind of refactor loses some appeal. [Though one could require all callers to accept either ',' or '-' as the delimiter.]
