Re: NetworkManager and suspend

[David Zeuthen <davidz redhat com>]

On Thu, 2005-02-03 at 15:21 -0500, Dan Williams wrote:
> On Thu, 2005-02-03 at 21:08 +0100, Rene Rask wrote:
> > Is NetworkManager able to detect changes in state like S3/S4/S5 and
> > recover from it? or should I edit my suspend script and restart
> 
> Nope, NM is blissfully unaware of power management right now, which is
> wrong.  I haven't had time to look at it though.  Interestingly enough,
> what usually happens in the suspend scripts that people have is that
> they 'rmmod airo' or 'rmmod ee1000'.

It's really a bug people need to write such scripts. Oh well,
let me stop ranting :-)

>   That signals HAL that the driver
> is gone, and it will then signal NetworkManager that to remove that
> device from its list.  When you wake up, the scripts commonly have
> 'modprobe airo' or whatever and that makes HAL signal NM of a new
> device.  In any case, if the driver supports sleep I don't think this
> dance is necessary, and NetworkManager doesn't deal wtih that case yet.
> 

Not really yet, but in the 0.5.x branch (hal HEAD) hal will know about
when logical devices are bound/unbound to physical devices. Right now
it doesn't work too well; stay tuned..

> > I must admit I have no idea if hal and dbus are usable for acpi stuff.
> 
> HAL is just now getting ACPI/APM support so that it knows the states of
> various buttons and such. 

That's not really related to this though.

>  I'm not sure how user applications figure out
> when the system goes to sleep or when it wakes up though.
> NetworkManager will definitely need to intercept these signals (whether
> they come from elsewhere or eventually from HAL or a 'power daemon' of
> some sort) and shut down all devices, then bring them back up on wake.
> 

The kernel does all that - without emitting hotplug events IIRC. I
think when the system wakes up the kernel sends out a delta of what
changed since it was put to sleep. But last time I removed a USB
device while the system was suspended it just didn't want to 
resume. Maybe it's better now.

> I'd imagine that when NM got a "sleep" signal from wherever, it would
> close all file descriptors related to that device, turn the device off
> (ie mark it as 'down'), and then wait until it gets the "awake" signal
> before starting things back up again.  That code needs to be done.
> 

It's not really clear to me yet how we want to approach this;
I think you're allowed to keep open file descriptors or sockets
during suspend but we need to look into ensuring that e.g.
NM does the right thing when the system is resumed. Definitely
something to look into..

Another issue, non-related though, is that we need some UI in NM
to disable wireless devices to comply with all the FAA's and
FCC's of the world. I expect that HAL just exports a Suspend()
method on the appropriate device (which effectively writes to
the power/state directory of the bus device, thus unbinding
the network class driver and HAL notifies NM of that this
networking device is no longer available) but it looks to
me like the kernel still needs some work - I can't get it
to work anyway...

David