On Mon, Jul 13, 2026 at 02:39:35AM +0200, Stefano Brivio wrote: > Nits only (pretty much for the whole series, even though I have > slightly more substantial remarks for 3/5 and 5/5, so I thought I'd > point all of them out): > > On Fri, 10 Jul 2026 16:56:07 +1000 > David Gibson wrote: > > > The semantics of --host-lo-to-ns-lo as described in the man page don't > > quite make sense: It says without the option forwarded packets will appear > > to come _from_ the guest's public address, which is not usually true. > > Instead the packets will arrive *to* the guest's public address. The exact > > semantics are also a bit confusing in general. > > > > Rewrite both the man page and code to clarify this. The new rule is that > > it redirects connections addressed to a host loopback address to the same > > loopback address in the guest. This is notionally different from what we > > had in two ways: > > * We can now deliver to nonstandard loopback addresses within the guest, > > not just the default one. This is technically a behavioural change, > > but I think will be less surprising behaviour. > > * The decision is now made on the original _destination_ address, rather > > than source address. That's different theoreically, but not in > > theoretically Oops, fixed. [snip] > > .TP > > .BR \-\-host-lo-to-ns-lo > > -If specified, connections forwarded with \fB\-t\fR and \fB\-u\fR from > > -the host's loopback address will appear on the loopback address in the > > -guest as well. Without this option such forwarded packets will appear > > -to come from the guest's public address. > > +If specified, connections to a host loopback address forwarded with > > +\fB\-t\fR or \fB\-u\fR will be delivered to the same loopback address > > +on the guest. Without this option such connections are forwarded to > > +the guest's public address. This option is incompatible with > > +\fB--no-splice\fR. > > Pre-existing, but still somewhat confusing: this is one part of the man > page where we don't specify "guest or namespace", we just use "guest", > and yet it's never a guest, it's always a namespace. > > Should we just change all the occurrences of "guest" to "namespace" in > this paragraph? Good idea, done. For future reference, in cases where it's less obvious which namespace we're talking about, how do you feel about "guest namespace". -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson