Seb,
Some initial thoughts on all of this:
* It's not clear to me that we will ultimately represent network
configuration via SMF, so I'm not sure that needs to be a gating
architectural factor.
* As you may recall, the original reason we did not put link ID
allocation into the kernel is that it would mean the kernel
would need to track state that is not tied to the running
configuration (e.g., because we preserve link IDs associated
with removed hardware, which dlmgmtd must track).
* It's not clear to me why these problems are unique to link IDs.
In particular, how have you chosen to tackle the problems of
duplicate link names in different zones, or duplicate link names
after a zone migration?
* Specifically with regard to link IDs, I think the cleanest
approach to explore would be removing them as we discussed
several months back. That is, if we can accept that the rename
facility should really have "replace" semantics, then we no
longer need to track link IDs since the name suffices. In this
model, dlmgmtd would still be used e.g. to track persistent
configuration associated with links associated with removed
hardware, but there would no longer be link IDs.
Assuming that removing link IDs is ultimately desirable but not
feasible right now, it's still valuable to consider since we
should choose a path that allows us to do that.
--
meem
