[ I am going through the UV inception issues list now... ]
jdc-2 "Is there a reason I'd want to do a temporary delete instead of (say) forcing the link down? (And can I force the link down?)" I have several questions regarding this: - What's the real user case that needs a "link down"? - After think it more, I don't think "link down" can solve all the scenario that "temporary delete" can solve. Assume that one wants to (temporarily) plumb an link which is a port of an established aggregation. (Note that one cannot plumb an link being aggregated). Today, one could temporarily delete this aggregation, and plumb that link. But "down" the aggregation won't work. wes-1 "In the absence of any way to map from a physical device path to a slot label, etc., shouldn't there at least be some way to associate an administratively-chosen descriptive field with each device?" Will we add this support? and how? In the form of a linkprop? Question 19 on uv_20q: 1. libdevinfo impact A general answer is that we will provide a dladm_walk() function to walk all the link names, and check all the places in ON to make sure every place calls libdevinfo needs to be changed to call dladm_walk(). But at the same time, I remembered that I also discussed the possibility that we might change the current libdevinfo implementation, to make the current di_walk_minor(DDI_NT_NET) to return nothing, (and to provide another form of libdevinfo function to walk the list of network devices), so that the application doing libdevinfo walking today will break badly, and will be changed to do the right thing in the earliest time. But since we won't change the default link name, I don't know whether this is still necessary. 2. access policy for network device (per-driver or per-link or default access policy only). I am thinking of keeping the current implementation as is (keep the the per-driver policy and not introduce the per-link one). If this is not a good idea, I will send a mail to the network-discuss alias to see whether there is anyone knows who is making use of the per-driver policy. Thanks - Cathy
