hi Cathy Cathy Zhou wrote: > >> 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? > That is correct. >> >> 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! > You mean to store the temporary linkname/linkid mappings under > temporary proptery groups, and persistent linkname/linkid mappings > should still be persisted, right? exactly. > I don't see a problem of that, as long as those information can be > easily looked up. > > But I personally think that temporary datalinks should also be > represented as SMF instances, as they do provide datalink services. > yeah, i can see that there's a reasonable argument to do this. i think the key question is whether we expect the SMF representation to be complete regarding what is configured on the system, versus being complete about what is _persistently_ configured on the system. the latter is probably less intuitive to administrators, but i don't know that that is such a big problem - my assumption is they'll be using dladm to query link status rather than "svcs datalink/*". the problem i see with exhaustively representing temporary configuration is having to undo the temporary portions of the configuration explicitly (i.e. the instances that were created via temporary commands) on reboot.
thanks! alan
