Re: [PATCH 15/18] pif: Limit pif names to IFNAMSIZ (16) bytes

[Stefano Brivio <sbrivio@redhat.com>]

On Fri, 27 Mar 2026 15:34:27 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> All current pif names are quite short, and we expect them to remain short
> when/if we allow arbitrary pifs.  However, because of the structure of
> the current code we don't enforce any limit on the length.
> 
> This will become more important with dynamic configuration updates, so
> start enforcing a length limit.  Specifically we allow pif names to be up
> to IFNAMSIZ bytes, including the terminating \0.  This is semi-arbitrary -
> there's no particular reason we have to use the same length limit as
> kernel netif names.  However, when we do allow arbitrary pifs, we expect
> that we might support a similar number to the number of kernel interfaces.
> It might make sense to use names matching kernel interface names in that
> future.  So, re-use IFNAMSIZ to avoid surprise.

And what if... we used 128 instead, which is reasonably longer than
UNIX_PATH_MAX (108, which despite the application usage in POSIX 2024.1:
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_un.h.html
is still commonly used a path length limit, also by passt itself)?

At that point we could embed UNIX domain socket paths as PIF name
(possibly with some additional specifier) which _might_ be useful to
forward UNIX sockets in the https://bugs.passt.top/show_bug.cgi?id=200
sense.

It's not the only way to implement it, but perhaps it's one possibility
that might make sense for what we know now? What do you think?

It also has the advantage of being sufficiently longer than IFNAMSIZ,
so that should we ever need to have stuff like "container_A:eth0" in a
PIF name, we could have it as well.

-- 
Stefano