On 19.06.2012 11:56, Roger Pau Monne wrote:
This should be done differently.
Rather than just change the name of the interface, create a layer
that maps a real device name to a network interface name.
Otherwise if you rename "tap0" to "bge3", how do you easily
determine that "bge3" is actually a tap device and not a bge?
I would like to add this functionality to the kernel, but can someone
provide a little bit more of technical information/steps about how to do
it?
(these are suggestions, there are countless ways to do that of course)
This needs some thought regarding the cleanliness of the API, but I
would do it through properties, just for reusability (instead of rolling
out your own API).
When a device gets created properties get attached to it (a proplib(3)
container). You can query those anytime for a device, see drvctl(8) code
for examples.
When attaching a new tap, you can keep the device information:
# drvctl -p tap0
Properties for device `tap0':
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
<plist version="1.0">
<dict>
<key>device-driver</key>
<string>tap</string>
<key>device-unit</key>
<integer>0x0</integer>
</dict>
</plist>
There, you see that the device-driver for a tap0 is "tap" (obviously).
You could add a member in this structure (string?) that would specify
the if_xname from struct ifnet, therefore pointing to the associated
interface name. Have a look to prop_dictionary_set(9) for an API to add
custom members to a property container.
Also, see sys/dev/pci/if_bnx.c, especially the prop_dictionary_set()
parts in bnx_attach. I used properties to move values between the PHY
and the NIC driver "safely." All credits for this idea goes to Izumi
Tsutsui.
Another possibility would be to add properties to ifnet structures, but
this would be redundant. I would expect interfaces and device names to
always match, so adding properties for ifnet structures is... kind of
useless (from my PoV).