Adding a field to ifnet to contain that alias, something like
if_xalias, then being able to set that name with an ioctl [...]
Is a maximum of one alias per interface sufficient? I once saw it said
that "the number two is ludicrous" - having one of something is fine,
but as soon as you have two, why not an unlimited number? In this
case, the "something" is names per interface.
Why draw a distinction between the name and the alias? (I actually can
see some potential answers to this; I mention it more to provoke
thought than because I think it's a serious issue.)
What I'm not sure is how to propagate that change to every tool that
interacts with network interfaces, we should of course change
ifconfig to be able to set/get this aliases, but then changes will
also be required to brconfig, pf...?
I see no need for all tools to be aware of aliases. Many (most?) tools
just use names to refer to interfaces and don't care about the finer
points of it. So as long as the names are valid for the purposes the
tools are using them for, I see no reason for, eg, brconfig to care
whether an interface it's trying to add is an alias or not.
Also, when the user specifies something like ifconfig alias:foo up,
how do we know to what is alias:foo mapped to?
Who is "we"? I see no reason for ifconfig to care; it just does the
ioctl with "alias:foo" in the interface name field and doesn't care
whether it's an alias, even, much less what it's an alias for. Inside
the kernel, for most purposes, this is entirely hidden within the "look
up an interface given its name" code; as far as I can see, the only
other things that have occasion to care are the specifcally alias-aware
ones, like the code to set and get alias names.