[Pm-utils] Add --print-reply to dbus-send to avoid dropping the message

[Stefan Seyfried]

On Fri, Sep 19, 2008 at 04:08:31PM +0100, Richard Hughes wrote:
> On Fri, 2008-09-19 at 09:57 -0500, Victor Lowther wrote:
> > On Fri, 2008-09-19 at 15:41 +0200, Stefan Seyfried wrote:
> > > On Fri, Sep 19, 2008 at 10:16:58AM +0100, Richard Hughes wrote:
> > > > Trivial patch attached to fix behaviour of dbus-send. Description and
> > > > solution in patch. Please review.
> > > 
> > > I think the --print-reply was removed, since it would slow down suspending
> > > considerably.
> 
> A single method to NetworkManager that's a NOP?

I think the problem was in the case when NetworkManager (or D-Bus?) was not
running or something like that. I am really not sure anymore about the exact
circumstances, but I seem to remember something like that.

I might of course be totally off track ;-)

> > > Couldn't we - at least for the suspend case - just put the dbus-send
> > > into the background? NM should be set to offline by g-p-m or kpowersave
> > > already anyway before pm-utils come into play, shouldn't it?
> > 
> > g-p-m appears to have done so for the last 3 years.
> 
> Sure, but doing the second "down" after the first is super quick, and
> works in the case of computers without g-p-m or kpowersave.

Yes. OTOH, people without a desktop powermanagement applet will probably also
not have NetworkManager ;-)

Note that I don't really feel strongly about the issue, it just triggered
some odd memories about why this was implemented the way it is. We can just
try what happens ;-)

> > Does network manager have a d-bus method that we can use to query its
> > current state?  If so, might be better to see if network manager is
> > already asleep, and do nothing on suspend/resume if that is the case.
> 
> IIRC, that's what the method already does, if already down then exit
> straight back.

This would IMVHO be the only impelementation to make sense, and I also guess
that it is the case.

> I guess the real question is that maybe we should just fix the kernel
> drivers rather than poke NM. I'll talk to Dan W.

Yes, that would probably be best. OTOH, telling the network to go down on
suspend (to make it damn clear to applications that they cannot expect the
connectionto persist) is probably not a bad idea, even if the drivers do
not need this.
-- 
Stefan Seyfried
R&D Team Mobile Devices            |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." 

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)