http://defect.opensolaris.org/bz/show_bug.cgi?id=11082
Renee Danson Sommerfeld <renee.danson at sun.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |renee.danson at sun.com
--- Comment #3 from Renee Danson Sommerfeld <renee.danson at sun.com>
2009-09-08 22:12:36 UTC ---
(In reply to comment #2)
> The actual location switching is done by the network/location service. nwamd
> sets the location/selected property for network/location and refreshes the
> service. On refresh, the setting for the new location are activated.
>
> During this process, the previously activated location is lost.
> network/location doesn't know what location was active when it is activating a
> new location.
>
> The fix for this bug requires that the previously activated location must be
> remembered. This, I am proposing, will be done in a new non-persistent
> property location/previous. Before changing the value of location/selected by
> nwamd, it copies the existing value to location/previous. Then, it writes the
> location to be activated in location/selected and refreshes network/location.
>
> Before network location activates the location in location/selected, it
> disables the SMF services in "enable-svcs" and enables the services in
> "disable-svcs" for the location/previous location. This basically are the
> opposite of actions network/location took while activating the
> location/previous location.
>
> Thoughts?
My first thought was that I didn't love this solution, but could not thing of a
better approach; so this was probably the way to go.
In thinking about it more, though, I'm concerned that there is really a larger
problem here. The problem is that we don't know what state the service in
question was in *before* the location that listed it in the enabled_svcs or
disabled_svcs property was activated. For the sake of discussion, assume you
have location foo that has enabled_svcs=svc1. So when you disable location
foo, that means you should disable svc1, right? But what if svc1 was enabled
before location foo was activated?
This is where enhanced smf profiles really do what we want, and our
approximation of that behavior really falls short. SMF profiles are layered on
top of each other, so earlier settings remain, they're just "covered" by the
setting in the profile. When the profile is removed, whatever the previous
setting was is uncovered.
Given that, I'm not sure carrying forward with this slightly broken attempt at
offering this functionality is the right thing to do. If there are services
that the user wants enabled or disabled when a particular location is active,
you can make that service a conditional enm that depends on the location state;
so it is possible to get similar functionality, in a way that makes it more
obvious what state things are in, and why.
--
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
