Re: using nm-system-settings for the user settings

[Dan Williams <dcbw redhat com>]

On Fri, 2009-05-15 at 00:09 +0200, Michael Biebl wrote:
> Dan Williams wrote:
> > On Thu, 2009-05-14 at 14:54 +0200, Martin Vidner wrote:
> >>
> >> Dan, Tambet told me that you intend to merge nm-system-settings into
> >> NM itself. I am afraid that it goes in pretty much the opposite
> >> direction than I would need. Could you share some details and
> >> reasons for the merge so that we can try to make the ideas work out
> >> together?
> > 
> > Reasons for the merge are:
> > 
> > (a) elimination of a running process
> > (b) reduce latency of unmanaged device discovery
> > (c) code reduction in NM because IPC between NM and the system settings
> > service would no longer be required
> > (d) ability to store more things like persistent Wireless Enabled,
> > Network Enabled, and device states in system config files
> > 
> > Basically, I didn't see a compelling case for it to still be separate
> > from NetworkManager.  Obviously the
> 
> There is one reason I can think of, why it still makes sense to keep
> nm-system-settings in a separate process:
> 
> You can easily restart nm-system-settings after changing it's configuration,
> without losing internet connection.
> 
> If NM could be fixed to not teardown an active connection on reload/restart, it
> would of course be even better.

I'll be doing that for non-802.1x/non-PPPoE ethernet connections in NM
0.8.  That is the only case for which this will be supported, because
all other connection types have entirely too much state.  Furthermore,
there must be an existing stored connection config that exactly matches
the existing device configuration when NM starts, otherwise the device
will be reconfigured to the "best" connection at that time.

The target use-cases are seamless restart of NetworkManager on an
ethernet connected server, and assumption of existing IP configuration
from an iSCSI configured by the initrd so that your rootfs doesn't go
poof on boot.

Dan