On Mon, Feb 13, 2006 at 06:19:40PM -0800, John Beck wrote:
> http://www.opensolaris.org/os/community/approachability/nwam/architecture/
- "
* At boot, the profile daemon consults the repository for the current
active profile and configures the network(s) accordingly. It is not
yet clear whether:
* the active profile is always persistent across reboots
or
* there may be support for a temporarily active profile which does
not persist across reboots
"
Mobile systems definitely need the latter as you cannot rely on any
network being available at boot time.
- Tunnels shouldn't get plumbed/unplumbed from without NWAM, no?
- We need control over what profiles can be transitioned to from what
profiles automatically without user input. For security, of course.
E.g., it'd be OK to transition to wired network from wireless
networks, if there's only one wired profile (if there's more than one
wired profile then detecting which it is securely, if that's desired
can be difficult).
So, rather than a boolean property indicating whether it's ok to
transition to a given profile, maybe have a property whose value is a
set of profiles that one can switch to this one from without user
input.
- Generally, I've cooled to the ide of automatic transitions w/o user
input, but at least being able to pop up a dialog when networks come
and go will be very nice.
- The easiest way to do damping would be to not do automatic network
transitions w/o user input.
- For user GUI interaction you may need to have users register at logon
time (e.g., by adding/starting a JDS panel applet). Alternatively
you can always look for the display running on the console (NWAM
isn't applicable to multi-seat systems, is it?).
(Aside: is it possible to open a dialog that doesn't take keyboard
focus? I hate dialogs that pop up while I'm typing away...)
- Possible states:
o No (null) profile selected
o Profile XYZ selected, network up
o Profile XYZ selected, network coming up
o Profile XYZ selected, network going down
o Profile XYZ selected, network lost/down/not visible, wait for
input/event to cause transition
o Profile XYZ selected, network lost/down/not visible, transition
timer set, transition to null profile
o Profile XYZ selected, network lost/down/not visible, transition
timer set, transition to UVW profile
- sysevents doesn't support consumers in non-global zones, IIRC
- how about using user-defined events for event ports, or doors instead
of sysevents? (If only user-defined events could bear data -- as it
is they are pointers to nothing in particular)
- it'd be nice if wireless drivers could cause route socket events when
networks become visible (dropping out of sight is another story, I
think, and we must mind APs that don't broadcast beacons).
- an ARC case was just submitted for adding a route socket message for
interface plumb/unplumb events. I'm sure you're aware.
- What name service... For the time being use a nsswitch file
extension name (/etc/nsswitch.{ldap, dns, ...}.
Nico
--
