Hi, I am looking at the NWAM code and trying to understand what changes will be needed for NWAM to work with the Clearview vanity naming component.
As I understand, that NWAM will plumb *all* the interfaces first right after it starts the NWAM daemon. If this is the case, we don't need to consider how it is going to interact with a link renaming operation, as a link will not be able to be renamed if it is opened. So, I am thinking of add a "linkid" field in the "struct interface", so that we don't need to convert the link name to linkid whenever we need that linkid when calling the libdladm functions. I am also considering to add an "interface type" field, so that we don't need to find out the type of the interface every time when we need to so. There are several other questions regarding the NWAM implementation though (not directly related to dladm rename-link): It seems that NWAM supposedly can work in an exclusive zone, and I saw that /etc/dladm/*.conf (so far, including /etc/dladm/linkprop.conf, /etc/dladm/aggregation.conf and /etc/dladm/secobj.conf) are exported to the local zone as well. But as the dladm command cannot be used in the local zone (yet), these configuration files will be always empty. Therefore: 1. If I understand correctly, the dladm_init_prop() function called in initialize_interfaces() is only useful in the global zone. Is that right? 2. Also, another serious problem I see when NWAM runs in a local zone is that the store_key() function. Note that the dladm_set_secobj() function will need the DLD_CONTROL_DEV node, which is not available in a local zone. It also update the /etc/dladm/secobj.conf in the local zone, which I don't know if it is the intention. 3. I don't think wpad can work in the local zone either. The kernel device tries to use the /var/run/wpa_door_<devname> door in the root directory of the global zone, and the application will only create that door in the root directory of the local zone. Maybe I missed something. Please let me know your opinion. Thanks - Cathy
