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

[Thomas Graf <tgraf redhat com>]

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.

> 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.