code review request for the changes discussed in this thread. The
associated bugs are 8790 and 8939, and the webrev is at
http://zhadum.east/export/ws/am223141/checkout-area/nwam1-fixes/webrev/
Thanks,
Anurag
>
> The Automatic NCP will to totally automatic with the following features:
>
> * wired interfaces are preferred over wireless interfaces
> * all wired interfaces are in the same shared priority-group
> * all wireless interfaces are in the same exclusive priority-group
> * NCUs for hotplugged and newly discovered interfaces are created as
> above
> * NCUs are removed when interfaces are hot(un)plugged or not found
> during nwamd startup
> ** The result is that only interfaces that currently exist in the
> system have NCUs.
>
> The User NCP will be all manual.
>
> * The user does everything.
> * No NCUs will be added or removed by nwamd.
> * NCUs added with manual activation-mode will be enabled by default
> ====> Change this behavior to "disabled by default"?
>
> Upgrading from Phase 0/0.5 to Phase 1
>
> * Known WLANs (for unique ESSIDs) will be created in the same priority
> order as in /etc/nwam/known_wifi_nets.
> * The existing /etc/nwam/llp file will be upgraded to the User NCP.
> * The User will be placed in the Automatic NCP.
> * manpage, spec, online help, wiki, etc. and release notes will say
> that the old configuration has been upgraded to the User NCP and users
> can switch to that NCP at the convenience.
> * The GUI may or may not do a one-time pop-up.
>
> Did I miss out any details?
>
> Anurag
>
>
>
> John Leser wrote:
>> Hi folks,
>>
>> I'm sending this out to close the loop on some hallways discussion
>> earlier today regarding how existing NWAM 0/.5 state will be handle
>> when the system is upgraded to phase 1.
>>
>> Prior to our discussion, the plan was that during an upgrade to NWAM
>> 1.0, existing NWAM state would migrated into the User NCP, and the
>> User NCP would be enabled after the upgrade. This differs from a
>> newly installed system, which starts out with the Automatic NCP enabled.
>>
>> Thus, we end up with a set of users who's systems are running with
>> the User NCP, just because they happened to get to NWAM 1.0 via
>> upgrade rather than fresh install. AFAIK, this is independent of
>> whether they ever customized their previous NWAM configuration
>> through the GUI or by editing the llp files. This is a problem for a
>> number of reasons, most importantly:
>>
>> * Users end up with non-default NWAM 1.0 behavior, having likely
>> never expressed a desire for non-default behavior.
>>
>> * It is a significant, unnecessary difference in system
>> state/behavior between freshly installed and upgraded systems.
>>
>> * If users might have either Automatic or User NCUs active for such
>> an unrelated reason as install method, the line between the User and
>> Automatic NCP becomes blurred to the point where the distinction is
>> not helpful.
>>
>> With phase 1.0, I think we really, really want the Automatic NCP to
>> work for most run-of the mill laptop/desktop use cases. Due to a
>> variety of factors, it is not possible to reliably determine if a
>> user ever modified the NWAM 0/.5 configuration, so we cannot base NCP
>> selection or upgrade strategy on whether the old environment was
>> customized.
>>
>> Having outlined the concerns with the current method, the solution we
>> are now considering for upgrades is:
>>
>> 1. At upgrade time, migrate existing NWAM state into the User NCP.
>> 2. Always activate the Automatic NCP after an upgrade.
>> 3. At first interaction with the NWAM GUI, inform the user that the
>> previous configuration has been saved in into the User profile,
>> provide information about how to activate that NCP, but encourage
>> trying/sticking with the Automatic profile.
>> 4. Augment #3 with release notes/other documentation.
>>
>> The exact manner and wording of step 3. will be critical. Darren, I
>> don't know if you have any suggestions for how best this can be
>> handled through the GUI.
>>
>> -John
>> _______________________________________________
>> nwam-dev mailing list
>> nwam-dev at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/nwam-dev
> _______________________________________________
> nwam-dev mailing list
> nwam-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/nwam-dev
