hi Cathy thanks for the quick response!
Cathy Zhou wrote: > Alan Maguire wrote: >> hi folks >> >> i'm a bit confused about the need to store temporary configuration >> data in the link id management API, and i was wondering if you could >> help me understand the need to do this. >> >> are there other reasons that temporary data is stored in >> /var/run/datalink.conf >> other than that cited in section 2 of the Link Id Management Design - >> i.e. that this data is needed in the case of a restart of dlmgmtd? > > yes, that is the reason, and the temporary file is > /etc/svc/volatile/network-datalink-management.cache. > >> (i'm assuming in this case the temporary data is needed in order to >> apply all >> the temporary changes again rather than reverting to >> persistently-configured >> state - have i got this right?). >> > Note that the only temporary configuration saved in the > /etc/svc/volatile/network-datalink-management.cache file is the > <linkname, linkid> mapping, that those are only information need to be > recovered. hmm, so the linkname-linkid mapping information for temporary links is stored in the cache so that dlmgmtd can pick up all the temporary mappings on restart, and if the user creates any new datalinks, we avoid linkid clashes by having a stored (but not persistent-across-reboot) list of linkname-linkids. is that right? the reason i ask is in the SMF model, we'll have SMF instances for datalinks, and it seems a bit heavyweight to create an instance for a temporary datalink (we'd have to flag such instances to be deleted on reboot). i wonder if we could simply store the linkname/linkid mappings under temporary property groups (which disappear on reboot) under the datalink-management service instance? thanks! alan
