> "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?
> - 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? 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. But yes, we could add a
"comment" link property that's a free-form string. It just feels strange.
> 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.
> 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.
--
meem
