Comment 6 for bug 303159

The ifupdown interpretation of the mapping is:
a. If auto stanza exists run ifup $DEVICE at startup
b. When ifup $DEVICE is run for a mapping, run the mapping script, and
apply the config.

My personal preference for the ideal user-side experience for a mapping
device would be:
a. when device is not available hide all $MAPPING::$DEVICE virtual
configuration
b. when a device becomes available, and an auto stanza exists, run the
equivalent of ifup $DEVICE
c. when a device becomes available, and no auto stanza exists, offer the
user a choice, i.e. don't activate the device, activate one of the
$MAPPING::$DEVICE virtual connections, and a $MAPPING::automatic option
that runs the script.
d. if a device is available, but the user did not activate it at the
time it became available, then offer all $MAPPING::$DEVICE combinations

Feedback:
For this 1. and 2a. are fine.
I am not sure 2b. is correct if a mapping device is not locked, yet, but
available via hal. I'd prefer to export virtual configuration always
when a device is available via hal (if a list of configurations can be
made mutually exclusive). This is important, if only to allow the user
to override the script decision.
About 3. we should only run the single mapping script that this
hal-device-available event was for, not all of them, and only if the
auto stanza exists (see above).
for 4. you mean a reload of the interfaces file?