New in snv_93: dladm link property persistence
By artem on Jul 14, 2008
I once joined a pickup basketball game and one of my teammates only noticed me after three or four possessions. Another teammate tried to be supportive and used the word "stealth" to characterize my role in the game (my own choice was "zero impact"). Story of my life.
But sometimes that's a good thing. A lot of OS improvements are like that, incremental in nature, not visible to most users, but contributing to the overall movement towards better future. Not quite the shouting from the rooftops material, but noteworthy to geeks and search engines.
Such is my
recent putback, a followup to the earlier
Brussels framework putback. Originally, properties set via
dladm set-linkprop were not guaranteed to persist when a link was unplumbed and later replumbed.
One would have to reapply the properties using the undocumented
ifconfig link0 plumb dladm init-linkprop
My putback makes it automatic. No need to reapply the properties manually anymore.
What happens under the hood is a bit more complicated. dladm shows you all links the system knows about:
# dladm show-link LINK CLASS MTU STATE OVER bge0 phys 1500 up -- iprb0 phys 1500 unknown -- iprb1 phys 1500 unknown --
This information, along with link properties, is stored in /etc/dladm/datalink.conf. The kernel, however, only needs to know about links that are currently in use. What the kernel knows can be extracted from mdb:
# mdb -k > \*i_dls_devnet_id_hash::modhash -e | ::modent -v | ::print dls_devnet_t dd_spa dd_spa = [ "bge0/0" ]
Generally, a link becomes in use when its corresponding device file under /dev/net
is first opened. That's what happens, for instance, when you plumb the link.
This is the moment the kernel learns about the link. This is also the moment
a new thread is launched, which communicates with the datalink management daemon,
dlmgmtd(1M). It requests the daemon to perform the equivalent of
dladm init-linkprop for this new link. The daemon extracts property data from datalink.conf and pushes it into the kernel.
There are still two cases when persistence is not guaranteed: wifi links and private properties. The following CRs have been filed and are being worked on: