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? -- IFUPDOWN - connections that are mapped should be locked to the mapping device https://bugs.launchpad.net/bugs/303159 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
