Kacheong Poon wrote: > Cathy Zhou wrote: > >> 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. > > > It is not clear what you meant by "interact with a link > renaming operation." Suppose NWAM provides a user the > ability to rename a link in phase 1. Is this considered > as an "interaction?" And suppose a user renames bge0 to > net0. When NWAM starts, will NWAM see net0 or bge0 so > that it will plumb the correct one? Is this considered as > an "interaction?" > Sorry that I wasn't clear. But this thread strictly talks about phase 0 (which has already been in Nevada). Can you have a second look to see whether the point in this thread is valid for phase 0?
> >> 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. > > > Do you mean the current nwamd's "struct interface?" We > are implementing phase 1 of NWAM. And I expect the > current nwamd's "struct interface" will go away. > > >> It seems that NWAM supposedly can work in an exclusive zone, > > > Do you mean NWAM phase 1 or 0? > > >> 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. > > > It seems that the above referred to phase 0. I > think NWAM phase 0 only targets to work in the global > zone. > Okay. I asked because I tried and found that the network/nwam service does exist in the local zone. It also has a function call lookup_zonename() in its code. I will have another look of the NWAM document, then I will bring the NWAM phase 1 work in to the discussion. - Cathy
