Max wrote: > Yes, if we compare "ifconfig + /etc/hostname.xxx" with "dladm -t + smf > instances", it seems obvious that we should completely ignore changes > done by 'dladm -t' and keep smf instance intact. But, I'm not sure if > that comparison is fully valid... :-\ > > The problem I see here is that saving persistent configuration in a > plain file is somewhat different than saving it in an smf instance. > A plain file can save the configuration, no more, no less. You won't be > able to tell if that configuration has been applied, or not, by only > checking the file containing the configuration. So, no matter how many > times you run ifconfig, there is no point to modify /etc/hostname.xxx > since that file does not contain any information needs modifying. > But, we have a 'state' (online, offline, etc...) associated w/ each smf > instance for sysadmin to check any time he wants. Thus, we actually keep > more information in smf instance besides the configuration itself. > I'm wondering what is the best way to handle these extra information > (comparing w/ a plain file database)...for example, if the instance is > 'online', should we view it as "the configuration has ever been > successfully applied, but whether it is still there is unknown"? > > Max
Peter wrote: > Yes. But in the case where the dladm -t request conflicts with the SMF > configuration, what happens? Should the service instance remain online > and pay no mind to the fact that the configuration is now different from > what it had configured? These are the same question, so I'll answer once. First off, the state isn't part of the configuration in SMF either: the config is what is saved in the repository, the service state is what is saved in memory in svc.startd. In terms of your question, I think all that is required here is decide on some reasonable semantics for existing service instances. The one that comes to my mind is temporary disable (equivalent of svcadm disable -t). i.e. if I use dladm -t to modify something and an instance exists in SMF for that and it is enabled, then dladm -t temporarily disables it. The semantics of temporary disable already means that it will return on next reboot, so that seems to fit. Anyway, think it through. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
