Re: [PATCH 6/9] device: Postpone auto-activation of a slave until its master is present

[Dan Williams <dcbw redhat com>]

On Tue, 2011-10-11 at 16:35 +0200, Thomas Graf wrote:
> On Tue, 2011-10-11 at 09:27 -0500, Dan Williams wrote:
> > On Fri, 2011-09-23 at 14:52 +0200, Thomas Graf wrote:
> > > When a slave is activated, it waits for the master device to appear. Once
> > > the master is present, it acquires a reference which is released again
> > > when the slave is deactivated.
> > 
> > So here, can you explain the logic a bit more?  As far as I can tell,
> > this happens before the slave is actually activated?  So to activate a
> > slave requires that the master interface is created and in the
> > NMManager's device list?
> 
> Yes, activation is postponed until the master interface has been
> created.
> 
> > If that's the case, I'd rather we do the check in the NMDevice
> > subclass' (NMDeviceEthernet for the slave, right?)
> > get_best_auto_connection() virtual method instead of in the policy.
> > Yes, that would require grabbing the manager with nm_manager_get() like
> > the OLPC Mesh subclass does, but whatever.  In the future I think we
> > should make NMManager implement a DeviceProvider GInterface and pass
> > that interface to each device as we create it so they have access to the
> > device list right when they are created.  The device subclasses don't
> > need all the manager stuff, and it would be good to create a clearer
> > separation there.  But that's an easy cleanup patch for later.  Now we
> > can just use nm_manager_get().
> 
> I have put this in the policy in order for it to be used by other device
> types in the future. VLAN will require the same dependency code but in
> the opposite direction, i.e. "eth0.10" activation must be postponed
> until "eth0" is present. Same is true for bridging.
> 
> The way it is implement now is that any device setting can specify a
> master which must be present prior to activation.

Ok, fine for now I suppose.

> > Also the ACT_STAGE_RETURN_XX stuff should probably only be used during
> > activation in nm-device files instead of elsewhere, I have grand plans
> > for that going away in the future to make the device activation flow a
> > lot more flexible.
> 
> OK, I can easily make this a True/False decision.

Yeah, if you could.  In the patch the FAILURE case is never hit either
so we can drop that hunk.

Dan