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. > I think that you are suggesting to do something similar, but your > change implies that all users of net interfaces should read the name > from the property list instead of reading it from the ifnet struct? So > if_xname remains the same, but the callers should instead read the > name from this property list? I think the properties suggestion was simpler - just have a way to add a name, and have the program that wants to use extraname=foo look over the interfaces to see which has the extraname property set to foo and then just use that one. Don't change anything else. > Or the name cannot be changed directly in the ifnet struct because it > represents the type of network interface, so changing tapX to foobar > will make the system think it's an unknown interface? There are two issues: the name in struct ifnet gets used in various other places, so changing it safely is hard (but remove/attach might be ok). This is the real issue. changing tapX to foobar means that you can't tell what kind of device it is by the name, but it's easy enough to require that the prefix not be changed and then be followed by a number, or some similar rule.
Attachment:
pgpHIepxkp8yh.pgp
Description: PGP signature