On Wed, May 20, 2009 at 4:08 PM, Dan Williams <d...@redhat.com> wrote: > On Wed, 2009-05-20 at 09:40 -0700, Dan Nicholson wrote: >> On Fri, May 15, 2009 at 4:34 PM, Dan Williams <d...@redhat.com> wrote: >> > On Fri, 2009-05-15 at 16:25 +0200, Christopher Lang wrote: >> >> Dan, >> >> >> >> thanks, for pointing me into the right direction, the >> >> https://bugzilla.redhat.com/show_bug.cgi?id=477964 has it all. >> >> >> >> >> >> However I would like to point out a few inconsistencies, that are still >> >> present in git repositories: >> >> >> >> 1. git repo from today, NetworkManager: >> >> file NetworkManager/initscript/Arch/networkmanager.in >> >> >> >> This one is using --type=method_call \ in the dbus-send, which is >> >> non-blocking, but makes dbus-send use "dbus_message_new_method_call" to >> >> set >> >> up the message, rather than "dbus_message_new_signal" >> > >> > I wasn't aware arch had that functionality actually; that should be >> > fixed. >> > >> >> 2. git repo from today, pm-utils: >> >> file pm-utils/pm/sleep.d/55NetworkManager >> >> >> >> This one still has the dbus-send without anything, no --print-reply and >> >> no --type=method_call. >> > >> > right, I believe upstream pm-utils was leaning towards fixing dbus >> > rather than this hack, but given that I don't believe upstream dbus will >> > fix the issue soon, we may have to go back to pm-utils upstream and >> > convince them to take the fix. >> >> I don't mind if it has to be done as a workaround in pm-utils, I'm >> just concerned that it will bitrot and the real fix will never happen. >> NM (Dan) has been such a huge advocate of "fix the drivers instead of >> papering over it", and I believe that has had a massively positive >> effect in the long term. I'd at least like to get an idea of what the >> real issue is with dbus-send and what it would take to get it fixed >> before pushing this into upstream pm-utils so everyone can have resume >> slowed down by 2 seconds. > > The real fix here is to figure out if the kernel sends uevents for > resume, and then make NM just listen to those. WE don't really need to > do anything on *suspend*, but we do need to know about resume so we can > clear the AP lists. We could also trust HAL/udev to tell use about > remove/add events that happened while the system was asleep (if they > lie, then they need to get fixed themselves to do that).
Good point. I wonder why there's no resume uevent. Hmm, found this old thread: https://lists.linux-foundation.org/pipermail/linux-pm/2005-March/006504.html > Thus, the only thing we'd care about would be resume, and we could > forget pm-utils altogether. > > If you want to go looking further into D-Bus, Michael Meeks kicked off > the discussion about this problem back in March 2008 I believe. Google > would probably have his mail and the thread on the dbus devel lists > about the issue. Until there's another way, I think it has to be with dbus from pm-utils. Here's the bug with all the links to the mailing list discussions and what not. It seems like it's had some traction over the past couple months. https://bugs.freedesktop.org/show_bug.cgi?id=896 It would be awesome if you could poke whoever the fedora dbus maintainer is (davidz?) and try to get that last patch into rawhide for some testing. -- Dan _______________________________________________ Pm-utils mailing list Pm-utils@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pm-utils
