On Wed, Nov 07, 2007 at 11:18:45AM +0800, Max Zhen wrote:
>
>
> Alan Maguire wrote:
> >
> > from a design perspective, we'd have to figure out
> > the semantics of administrator enable/disable.
> > and on the implementation side, i think the key intersection
> > is the delegated restarter. if we were to use the
> > same link instances in the NWAM and non-NWAM cases,
> > we'd need a common SMF delegated restarter external to
> > NWAM (since NWAM can be disabled) that carries out different
> > activities based on whether NWAM is enabled or not
> > (for example for wireless links, in the non-NWAM case
> > it might try to autoconf the wireless interface, while if
> > NWAM is running it'll consult the visited WLAN list,
> > etc.).
> >
> This can be done if we can change the SMF instance restarter on the fly.
> But, it seems to me like a duplicate effort, if we try to implement an
> external restarter besides nwamd.
I think the idea here is to separate out the delegated restarter
functionality. That would always be running, regardless of the
nwam service state. Then nwamd would handle the "automagic"
behavior, and would only run when the nwam service is enabled.
> > the other non-NWAM part of the puzzle would be
> > ensuring that administrator-driven activities (i.e. dladm
> > for link instances and ifconfig for IP SMF instances)
> > lead to state changes to the link or IP interface instances
> > (if we're representing links in SMF for the non-NWAM
> > case, i'm assuming that we'd need to represent IP interfaces
> > too?). i'm probably missing something, but they are
> > the two major pieces that occur to me offhand. thanks!
> >
> Again, to implement IP SMF instances when nwamd is not enabled seems to
> be another duplicate effort, not only on the implementation, but also on
> all the related testing work we need to do.
The point is that the instances exist whether nwam is enabled or
not; there are different ways to change their configuration (dladm,
nwam gui, nwam cli, svccfg) and different management approaches
("manual", which is similar to the existing network/physical:default
approach, and nwam). But there's no duplication, because there's
only one sfm framework.
That's not to say that this change will not have impact on the phase
1 effort; it will be more work. But I think the end result will be
a step forward for the non-nwam case as well as for nwam itself, and
is the only sensible way I can see to handle a unified (for both nwam
and non-nwam scenarios) configuration repository within the smf
framework.
> I'm wondering if we can split the functionality of nwamd into two parts
> - SMF restarter and auto-switching. So, we can always enable restarter
> part, while make auto-swithing part more flexible (can be
> disabled/enabled). To some extend, the restarter part is something like
> the 'external restarter' mentioned by Alan...
Right, I think that's the direction we're headed.
-renee
