'help' to

venkateswarlu rachamalla venkatr10 at gmail.com
Tue Mar 6 23:02:16 PST 2007 

On 10/19/06, dbus-request at lists.freedesktop.org <
dbus-request at lists.freedesktop.org> wrote:
>
> Send dbus mailing list submissions to
>         dbus at lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.freedesktop.org/mailman/listinfo/dbus
> or, via email, send a message with subject or body 'help' to
>         dbus-request at lists.freedesktop.org
>
> You can reach the person managing the list at
>         dbus-owner at lists.freedesktop.org
>
> 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" <johnp at redhat.com>
> Subject: Re: PATCH: configure error when cross compiling dbus core
>         0.94
> To: Marco Pracucci <development at pracucci.com>
> Cc: Dbus Mailing list <dbus at lists.freedesktop.org>
> Message-ID: <1161200000.3155.34.camel at 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 <johnp at redhat.com>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 19 Oct 2006 10:27:07 -0400
> From: Havoc Pennington <hp at redhat.com>
> Subject: Re: [rfc] move activation to a helper process
> To: David Zeuthen <david at fubar.dk>
> Cc: dbus at lists.freedesktop.org
> Message-ID: <45378B3B.3090002 at redhat.com>
> 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" <johnp at redhat.com>
> Subject: Re: [rfc] move activation to a helper process
> To: Havoc Pennington <hp at redhat.com>
> Cc: David Zeuthen <david at fubar.dk>, dbus at lists.freedesktop.org
> Message-ID: <1161268721.27822.6.camel at 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 <johnp at redhat.com>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 19 Oct 2006 10:53:37 -0400
> From: "John (J5) Palmieri" <johnp at redhat.com>
> Subject: [PATCH] run uuidgen --ensure in the init script
> To: Dbus Mailing list <dbus at lists.freedesktop.org>
> Message-ID: <1161269617.27822.13.camel at 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 <johnp at redhat.com>
> -------------- 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 :
> http://lists.freedesktop.org/archives/dbus/attachments/20061019/7e725dc7/dbus-run-uuidgen-on-init-0001.bin
>
> ------------------------------
>
> Message: 5
> Date: Thu, 19 Oct 2006 11:15:38 -0400
> From: Havoc Pennington <hp at redhat.com>
> Subject: Re: [rfc] move activation to a helper process
> To: "John (J5) Palmieri" <johnp at redhat.com>
> Cc: David Zeuthen <david at fubar.dk>, dbus at lists.freedesktop.org
> Message-ID: <4537969A.90806 at redhat.com>
> 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 <hp at redhat.com>
> Subject: Re: [PATCH] run uuidgen --ensure in the init script
> To: "John (J5) Palmieri" <johnp at redhat.com>
> Cc: Dbus Mailing list <dbus at lists.freedesktop.org>
> Message-ID: <453796DD.8050303 at redhat.com>
> 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 <hp at redhat.com>
> Subject: Re: [PATCH] run uuidgen --ensure in the init script
> To: "John (J5) Palmieri" <johnp at redhat.com>
> Cc: Dbus Mailing list <dbus at lists.freedesktop.org>
> Message-ID: <45379E74.1060601 at redhat.com>
> 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" <johnp at redhat.com>
> Subject: Re: [PATCH] run uuidgen --ensure in the init script
> To: Havoc Pennington <hp at redhat.com>
> Cc: Dbus Mailing list <dbus at lists.freedesktop.org>
> Message-ID: <1161274171.27822.28.camel at 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 <johnp at redhat.com>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: dbus-implement-reload.patch
> Type: text/x-patch
> Size: 1019 bytes
> Desc: not available
> Url :
> http://lists.freedesktop.org/archives/dbus/attachments/20061019/213ea0f1/dbus-implement-reload-0001.bin
>
> ------------------------------
>
> Message: 9
> Date: Thu, 19 Oct 2006 12:10:41 -0400
> From: Havoc Pennington <hp at redhat.com>
> Subject: Re: [PATCH] run uuidgen --ensure in the init script
> To: "John (J5) Palmieri" <johnp at redhat.com>
> Cc: Dbus Mailing list <dbus at lists.freedesktop.org>
> Message-ID: <4537A381.6060206 at redhat.com>
> 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" <johnp at redhat.com>
> Subject: Re: [PATCH] run uuidgen --ensure in the init script
> To: Havoc Pennington <hp at redhat.com>
> Cc: Dbus Mailing list <dbus at lists.freedesktop.org>
> Message-ID: <1161274680.27822.33.camel at 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 rc.messagebus.in just does a killall so I used the same
> convention.  I mean rc.messagebus.in seems broken in many cases such as
> not cleaning up the pid file.  messagebus.in 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 <johnp at redhat.com>
>
>
>
> ------------------------------
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>
>
> End of dbus Digest, Vol 15, Issue 32
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20070307/00a4a1cf/attachment-0001.html

More information about the dbus mailing list