Peter Memishian wrote: > > "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"? > > I'm not sure; what's the reason a real user would want to temporarily > delete a link? > The only case I can think of is that the user wants to use the associated device for other purpose. One example is the case I gave (to plumb the link directly instead of put it in an aggregation).
> > - 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. > > Or one could just temporarily remove that link from the aggregation and > plumb it, right? Only if this link is not the only port in the aggregation. But in most cases, yes. And I don't know why create an aggregation with a single port in the first place. > But yes, it wouldn't make sense to force a given link > down in this case. > > > 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? > > To me, this still feels like unrelated work. I agree. I think the comments originated from that user cannot tell the /devices path from the link name, but as there is no directly relationship between the /devices path and the physical slot number, I don't understad why /devices path is important. > But yes, we could add a > "comment" link property that's a free-form string. It just feels strange. > Personally, I don't like to support it though. > > 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. > > I think it's still worthwhile, though we might want to do it after the > initial putback. For instance, we could do: > > * Initial putback: compatible names by default; no change to > di_walk_minor(). > * Follow-up putback: change di_walk_minor(); examine and address > impact. > * Follow-up putback #2: vanity names by default; examine and > address impact. > If so, do we need to mention this phases plan in the PSARC document? > > 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). > > Seems like per-driver policy becomes effectively "random" after vanity > naming, so I'm not sure I like this approach. > > > 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. > > I think we should get that data. > I've sent the question. Thanks - Cathy
