[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Specifying names for tap interfaces
So, we would like to be able to create interface alias, here is what
I think should be doable (from my PoV):
Here are some thoughts that come to mind. I'm not sure they're all
points worth worrying about.
Thanks for the information, it has been really helpful.
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.
Well, I think that adding one or more than one is not really a problem.
I will start working on adding one alias per interface, but we can
always extend that code to add more than one.
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.
If it turns out there is reason for userland to care - and reason to
draw a distinction between an interface's alias and its real name -
then an interface could be added to return the real name corresponding
to a possibly-aliased name.
Well, now I have a clearer idea of what should be done, I will start
working on this tomorrow morning, let's see if I can get it ready for a
backport to 6.0.
Main Index |
Thread Index |