Port-xen archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Specifying names for tap interfaces



On Wed, Jun 20, 2012 at 07:47:19AM -0400, Greg Troxel wrote:
> 
> Roger Pau Monne <roger.pau%citrix.com@localhost> writes:
> 
> > Thanks for the input, I had no idea about this properties thing. I was
> > going to try to mimic what FreeBSD does:
> >
> > http://fxr.watson.org/fxr/source/net/if.c#L2194
> >
> > It creates a new ioctl called SIOCSIFNAME which basically detaches the
> > interface, changes the name (if_xname) and attaches the interface
> > again.
> 
> That seems doable, and I think there's merit to being similar to
> FreeBSD.  I suspect the interfaces for removal/addition will be
> different, but what if_tap.c does can just be adapted.  This scheme
> feels icky, but it doesn't seem wrong and it may be the lowest-pain path
> to getting xen/hvm working.

Yes, and I think it can be made more general than just tap and Xen
(whenever this should be another string in struct ifnet, or a XML
property of the device is another debate - lets talk about the functionality
we want first).

I think we could have both a device name and a device name alias for an
interface (lets call them xname and xalias for now). The xname would still
be as it is righ now (i.e. bge0 or tap3, bridge1, ...)
xalias is a user-settable string (ifconfig should probably be able to set it)
with the only constraint that it's unique in a system (and probably
lenght-limited). Consumer could refer to an interface by xname or by xalias,
with some way to differenciate xname and xalias (this could via a specific
syntax, e.g. alias:<string>).

Being able to refer to an interface by a user-settable name has more uses
than for Xen (Xen use cases have already been mentionned, I won't repeat
them). For example, on a system with a bnx0, for whatever reason,
the interface is remplaced with a wm(4). I have to change every place
listing interface names (ipf, altq, routing daemons, log analysers, mrtg, ....).
If I could give the interface a custom xalias and use it instead of xname,
the change would be almost transparent (only ifconfig.bnx0 to rename to
ifconfig.wm0).

I think this is more general and less trouble than the destroy/recreate with
a different name (the struct ifnet doesn't change). Changing the xalias on a
running system shouldn't cause more problem than e.g. xvif1-0 being destroyed
and xvif2-0 being created (it should actually be less trouble, because 
struct ifnet doesn't change). ipf -y will rescan the ifnet list for new
xnames and xaliases. If you actually change an interface's xalias and forget
to update ipf.conf; well, that's a user error :)

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--


Home | Main Index | Thread Index | Old Index