<div>On 10/19/06, <a href="mailto:dbus-request@lists.freedesktop.org">dbus-request@lists.freedesktop.org</a> <<a href="mailto:dbus-request@lists.freedesktop.org"> dbus-request@lists.freedesktop.org</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Send dbus mailing list submissions to         <a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a> To subscribe or unsubscribe via the World Wide Web, visit         <a href="http://lists.freedesktop.org/mailman/listinfo/dbus"> http://lists.freedesktop.org/mailman/listinfo/dbus</a> or, via email, send a message with subject or body 'help' to         <a href="mailto:dbus-request@lists.freedesktop.org">dbus-request@lists.freedesktop.org </a> You can reach the person managing the list at         <a href="mailto:dbus-owner@lists.freedesktop.org">dbus-owner@lists.freedesktop.org</a> When replying, please edit your Subject line so it is more specific than "Re: Contents of dbus digest..." Today's Topics:    1. Re: PATCH: configure error when cross compiling dbus core       0.94 (John (J5) Palmieri)    2. Re: [rfc] move activation to a helper process (Havoc Pennington)    3. Re: [rfc] move activation to a helper process (John (J5) Palmieri)    4. [PATCH] run uuidgen --ensure in the init script       (John (J5) Palmieri)    5. Re: [rfc] move activation to a helper process (Havoc Pennington)    6. Re: [PATCH] run uuidgen --ensure in the init script       (Havoc Pennington)    7. Re: [PATCH] run uuidgen --ensure in the init script       (Havoc Pennington)    8. Re: [PATCH] run uuidgen --ensure in the init script       (John (J5) Palmieri)    9. Re: [PATCH] run uuidgen --ensure in the init script       (Havoc Pennington)   10. Re: [PATCH] run uuidgen --ensure in the init script       (John (J5) Palmieri) ---------------------------------------------------------------------- Message: 1 Date: Wed, 18 Oct 2006 15:33:20 -0400 From: "John (J5) Palmieri" <<a href="mailto:johnp@redhat.com">johnp@redhat.com </a>> Subject: Re: PATCH: configure error when cross compiling dbus core         0.94 To: Marco Pracucci <<a href="mailto:development@pracucci.com">development@pracucci.com</a>> Cc: Dbus Mailing list < <a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a>> Message-ID: <1161200000.3155.34.camel@phuket> Content-Type: text/plain On Wed, 2006-10-18 at 19:26 +0000, Marco Pracucci wrote: > Hi John, > > Doh, I thought I caught all these.  Which is correct?  AC_TRY_RUN or > > AC_RUN_IF_ELSE.  I saw reference in the autoconf manual in the cross > > compiling section that one of them was deprecated but from the language > > I couldn't figure out which one (apparently we use both). > > > |AC_TRY_RUN| has been marked as obsolete and has been replaced with > |AC_RUN_IFELSE|. > > Patch looks good.  If you could, could you check the other AC_TRY_RUN > > macros and fix them up if they are wrong.  Thanks. > > > | > | I've replaced the two instances of AC_TRY_RUN with AC_RUN_IFELSE. I've > attached a cumulative patch below. Thanks for the patch, committing it now.  Next time it would be nice if you send it as an attachment.  My mail client changed tabs to spaces and added CR's.  I had to manually apply the diff.  Hopefully now cross compile issues are behind us. -- John (J5) Palmieri <<a href="mailto:johnp@redhat.com">johnp@redhat.com</a>> ------------------------------ Message: 2 Date: Thu, 19 Oct 2006 10:27:07 -0400 From: Havoc Pennington <<a href="mailto:hp@redhat.com">hp@redhat.com</a>> Subject: Re: [rfc] move activation to a helper process To: David Zeuthen <<a href="mailto:david@fubar.dk">david@fubar.dk</a>> Cc: <a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a> Message-ID: <<a href="mailto:45378B3B.3090002@redhat.com">45378B3B.3090002@redhat.com</a>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi, This is sort of a half-review, but a few comments from skimming:   - Sending all those DBUS_MAXIMUM_NAME_LENGTH blocks that are usually     mostly-nul seems a little wasteful, despite premature optimization     and all that ...   - Why not send the .service file name instead of the bus name to     activate, then we don't need the inefficient     _scan_service_dir_for_desktop_file   - the fork-without-exec is inherently somewhat confusing, I think     a nice way to make it clearer would be to have a single     file where all code runs in the child, exporting one     function like bus_activation_helper_start_child(),     where this function is called in the child immediately post-fork.     but I don't know if this is easily done. I think it'd be     nicer to split the BusActivationHelper struct up instead of having     the in_helper flag, also.   - breaking up the handle_watch function would improve readability   - in handle_bus_pipe the "should never happen" should use _dbus_warn     or _dbus_assert_not_reached so we can see it if it does   - the system headers (especially unix-specific ones) aren't allowed     in bus/*.c in general; the current exception is dir-watch-* which     is configure-protected. string.h is allowed but almost always     DBusString should be used instead (trivial strcmp, strlen is OK,     but if you're doing pointer math, DBusString is much safer)     The minimum fix is just wrap all the system calls in a trivial way     in dbus-sysdeps-unix.[hc], better though is to come up with a     higher-level wrapper that could work on windows ... probably on     windows it needs to use threads instead of fork ... remember that     the sysdeps abstractions don't need to be glib/nspr-worthy, they     can be a little ad hoc or special purpose.     One thought is to encapsulate the two pipes and make them look     like a full duplex pipe (could even use socketpair when available)     and allow using some other mechanism on windows; and then also     encapsulate threads vs. process. so basically have "run this     code async in another thread or process, with a full duplex     stream to talk to it" as the abstraction. The stream might     have its own read/write methods, since I don't think using sockets     on windows will make sense, which means the current _dbus_read_socket     etc. won't work.   - officially at the moment dbus_uint64_t is "optional" (requires     DBUS_HAVE_INT64 checks) but I think GLib and Qt both require 64-bit     int now, so making it optional is probably stupid. I was just copying     older glib here and I don't think anyone is aware of a     currently-interesting platform that lacks int64. Havoc ------------------------------ Message: 3 Date: Thu, 19 Oct 2006 10:38:41 -0400 From: "John (J5) Palmieri" <<a href="mailto:johnp@redhat.com"> johnp@redhat.com</a>> Subject: Re: [rfc] move activation to a helper process To: Havoc Pennington <<a href="mailto:hp@redhat.com">hp@redhat.com</a>> Cc: David Zeuthen <<a href="mailto:david@fubar.dk"> david@fubar.dk</a>>, <a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a> Message-ID: <1161268721.27822.6.camel@phuket> Content-Type: text/plain On Thu, 2006-10-19 at 10:27 -0400, Havoc Pennington wrote: > Hi, > > This is sort of a half-review, but a few comments from skimming: > >   - Sending all those DBUS_MAXIMUM_NAME_LENGTH blocks that are usually >     mostly-nul seems a little wasteful, despite premature optimization >     and all that ... >   - Why not send the .service file name instead of the bus name to >     activate, then we don't need the inefficient >     _scan_service_dir_for_desktop_file I would rather not have the bus tied to the .service file and instead leave that as an implementation detail for the daemon (perhaps with some standard behind it).  The reason I say this is on OLPC we might want to make our own daemon which forks and loads python files to avoid the overhead of loading another instance of python. The daemon itself should cache service files the way D-Bus does now. -- John (J5) Palmieri <<a href="mailto:johnp@redhat.com">johnp@redhat.com</a>> ------------------------------ Message: 4 Date: Thu, 19 Oct 2006 10:53:37 -0400 From: "John (J5) Palmieri" <<a href="mailto:johnp@redhat.com">johnp@redhat.com</a>> Subject: [PATCH] run uuidgen --ensure in the init script To: Dbus Mailing list <<a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a>> Message-ID: <1161269617.27822.13.camel@phuket> Content-Type: text/plain; charset="us-ascii" Distros that run a session bus without a system bus will have to do it some other way but this covers both mainstream installed distros and stateless systems like livecds.  That is assuming a stateless system has a writable /etc.  If this is not the norm we should figure out a better place to put the machine-id file. -- John (J5) Palmieri <<a href="mailto:johnp@redhat.com">johnp@redhat.com</a>> -------------- next part -------------- A non-text attachment was scrubbed... Name: dbus-run-uuidgen-on-init.patch Type: text/x-patch Size: 1156 bytes Desc: not available Url : <a href="http://lists.freedesktop.org/archives/dbus/attachments/20061019/7e725dc7/dbus-run-uuidgen-on-init-0001.bin"> http://lists.freedesktop.org/archives/dbus/attachments/20061019/7e725dc7/dbus-run-uuidgen-on-init-0001.bin</a> ------------------------------ Message: 5 Date: Thu, 19 Oct 2006 11:15:38 -0400 From: Havoc Pennington < <a href="mailto:hp@redhat.com">hp@redhat.com</a>> Subject: Re: [rfc] move activation to a helper process To: "John (J5) Palmieri" <<a href="mailto:johnp@redhat.com">johnp@redhat.com</a>> Cc: David Zeuthen < <a href="mailto:david@fubar.dk">david@fubar.dk</a>>, <a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a> Message-ID: <<a href="mailto:4537969A.90806@redhat.com">4537969A.90806@redhat.com</a> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed John (J5) Palmieri wrote: > I would rather not have the bus tied to the .service file and instead > leave that as an implementation detail for the daemon (perhaps with some > standard behind it).  The reason I say this is on OLPC we might want to > make our own daemon which forks and loads python files to avoid the > overhead of loading another instance of python. > > The daemon itself should cache service files the way D-Bus does now. > I don't think this is related to this patch, though. The helper is an implementation detail of the bus daemon, it is not any kind of public interface (OLPC would not for example want to provide a replacement helper, or at least there's certainly no provision in this patch to enable that). If we want to make activation pluggable I'd suggest that we do something like: apps can own the org.freedesktop.DBus.ServiceFactory bus name, and if that name is owned the bus asks it to launch stuff either before or after it looks at .service files. This is probably fairly questionable on the system bus, but then having the system bus spawning python stuff seems avoidable. Havoc ------------------------------ Message: 6 Date: Thu, 19 Oct 2006 11:16:45 -0400 From: Havoc Pennington <<a href="mailto:hp@redhat.com"> hp@redhat.com</a>> Subject: Re: [PATCH] run uuidgen --ensure in the init script To: "John (J5) Palmieri" <<a href="mailto:johnp@redhat.com">johnp@redhat.com</a>> Cc: Dbus Mailing list <<a href="mailto:dbus@lists.freedesktop.org"> dbus@lists.freedesktop.org</a>> Message-ID: <<a href="mailto:453796DD.8050303@redhat.com">453796DD.8050303@redhat.com</a>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed John (J5) Palmieri wrote: > Distros that run a session bus without a system bus will have to do it > some other way but this covers both mainstream installed distros and > stateless systems like livecds.  That is assuming a stateless system has > a writable /etc.  If this is not the norm we should figure out a better > place to put the machine-id file. > This patch looks fine, I think we should go ahead and put the machine id in /var anyway but that won't affect this patch. Havoc ------------------------------ Message: 7 Date: Thu, 19 Oct 2006 11:49:08 -0400 From: Havoc Pennington <<a href="mailto:hp@redhat.com">hp@redhat.com</a>> Subject: Re: [PATCH] run uuidgen --ensure in the init script To: "John (J5) Palmieri" <<a href="mailto:johnp@redhat.com">johnp@redhat.com</a>> Cc: Dbus Mailing list <<a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a>> Message-ID: < <a href="mailto:45379E74.1060601@redhat.com">45379E74.1060601@redhat.com</a>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed btw, just noticed that the init scripts don't implement reload since it wasn't possible originally, but they could now implement it since the daemon supports -HUP for that now I think Havoc ------------------------------ Message: 8 Date: Thu, 19 Oct 2006 12:09:31 -0400 From: "John (J5) Palmieri" <<a href="mailto:johnp@redhat.com">johnp@redhat.com</a>> Subject: Re: [PATCH] run uuidgen --ensure in the init script To: Havoc Pennington <<a href="mailto:hp@redhat.com"> hp@redhat.com</a>> Cc: Dbus Mailing list <<a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a>> Message-ID: <1161274171.27822.28.camel@phuket> Content-Type: text/plain; charset="us-ascii" On Thu, 2006-10-19 at 11:49 -0400, Havoc Pennington wrote: > btw, just noticed that the init scripts don't implement reload since it > wasn't possible originally, but they could now implement it since the > daemon supports -HUP for that now I think This should be correct. -- John (J5) Palmieri <<a href="mailto:johnp@redhat.com">johnp@redhat.com</a>> -------------- next part -------------- A non-text attachment was scrubbed... Name: dbus-implement-reload.patch Type: text/x-patch Size: 1019 bytes Desc: not available Url : <a href="http://lists.freedesktop.org/archives/dbus/attachments/20061019/213ea0f1/dbus-implement-reload-0001.bin"> http://lists.freedesktop.org/archives/dbus/attachments/20061019/213ea0f1/dbus-implement-reload-0001.bin</a> ------------------------------ Message: 9 Date: Thu, 19 Oct 2006 12:10:41 -0400 From: Havoc Pennington < <a href="mailto:hp@redhat.com">hp@redhat.com</a>> Subject: Re: [PATCH] run uuidgen --ensure in the init script To: "John (J5) Palmieri" <<a href="mailto:johnp@redhat.com">johnp@redhat.com</a>> Cc: Dbus Mailing list <<a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a>> Message-ID: <<a href="mailto:4537A381.6060206@redhat.com">4537A381.6060206@redhat.com</a>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed John (J5) Palmieri wrote: > On Thu, 2006-10-19 at 11:49 -0400, Havoc Pennington wrote: >> btw, just noticed that the init scripts don't implement reload since it >> wasn't possible originally, but they could now implement it since the >> daemon supports -HUP for that now I think > > This should be correct. > If the init script knows about a pid file presumably we can avoid killall and just kill the pid? I would expect some other init scripts already do this or even that one of the standard shell functions available to Fedora init scripts does this for you? Reload on HUP is pretty standard. This will HUP all session daemons also, is the main issue. Havoc ------------------------------ Message: 10 Date: Thu, 19 Oct 2006 12:18:00 -0400 From: "John (J5) Palmieri" <<a href="mailto:johnp@redhat.com">johnp@redhat.com</a>> Subject: Re: [PATCH] run uuidgen --ensure in the init script To: Havoc Pennington <<a href="mailto:hp@redhat.com">hp@redhat.com</a>> Cc: Dbus Mailing list <<a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org </a>> Message-ID: <1161274680.27822.33.camel@phuket> Content-Type: text/plain On Thu, 2006-10-19 at 12:10 -0400, Havoc Pennington wrote: > > John (J5) Palmieri wrote: > > On Thu, 2006-10-19 at 11:49 -0400, Havoc Pennington wrote: > >> btw, just noticed that the init scripts don't implement reload since it > >> wasn't possible originally, but they could now implement it since the > >> daemon supports -HUP for that now I think > > > > This should be correct. > > > > If the init script knows about a pid file presumably we can avoid > killall and just kill the pid? I would expect some other init scripts > already do this or even that one of the standard shell functions > available to Fedora init scripts does this for you? Reload on HUP is > pretty standard. > > This will HUP all session daemons also, is the main issue. The stop for <a href="http://rc.messagebus.in">rc.messagebus.in</a> just does a killall so I used the same convention.  I mean <a href="http://rc.messagebus.in">rc.messagebus.in</a> seems broken in many cases such as not cleaning up the pid file.  <a href="http://messagebus.in">messagebus.in</a> is the more sane Red Hat style scripts.  Perhaps someone who doesn't use the Red Hat style scripts should fix it up. -- John (J5) Palmieri <<a href="mailto:johnp@redhat.com">johnp@redhat.com</a>> ------------------------------ _______________________________________________ dbus mailing list <a href="mailto:dbus@lists.freedesktop.org"> dbus@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/dbus">http://lists.freedesktop.org/mailman/listinfo/dbus</a> End of dbus Digest, Vol 15, Issue 32 ************************************ </blockquote></div>