Linux-Bluetooth Archive on lore.kernel.org
 help / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH BlueZ 1/6] share/mainloop: Add handling of NOTIFY_SOCKET
Date: Tue, 27 Nov 2018 14:30:52 +0100
Message-ID: <1663DCEA-9B2E-4B2E-BE32-568A7D6CDA3E@holtmann.org> (raw)
In-Reply-To: <CABBYNZJ8zNu6Ub1Zo4ms0nX8CfgWjnXfR5d_My77VsC2q5Z1_g@mail.gmail.com>

Hi Luiz,

>>> This adds handling of systemd NOTIFY_SOCKET so application using
>>> mainloop instance do properly notify systemd what is their state.
>>> ---
>>> Makefile.am                  |   8 ++-
>>> src/shared/mainloop-glib.c   |   8 +++
>>> src/shared/mainloop-notify.c | 104 +++++++++++++++++++++++++++++++++++
>>> src/shared/mainloop-notify.h |  25 +++++++++
>>> src/shared/mainloop.c        |  12 ++++
>>> src/shared/mainloop.h        |   1 +
>>> 6 files changed, 156 insertions(+), 2 deletions(-)
>>> create mode 100644 src/shared/mainloop-notify.c
>>> create mode 100644 src/shared/mainloop-notify.h
>>> 
>>> diff --git a/Makefile.am b/Makefile.am
>>> index 0b26ccc3e..124c32482 100644
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>> @@ -130,12 +130,16 @@ endif
>>> src_libshared_glib_la_SOURCES = $(shared_sources) \
>>>                              src/shared/io-glib.c \
>>>                              src/shared/timeout-glib.c \
>>> -                             src/shared/mainloop-glib.c
>>> +                             src/shared/mainloop-glib.c \
>>> +                             src/shared/mainloop-notify.h \
>>> +                             src/shared/mainloop-notify.c
>>> 
>>> src_libshared_mainloop_la_SOURCES = $(shared_sources) \
>>>                              src/shared/io-mainloop.c \
>>>                              src/shared/timeout-mainloop.c \
>>> -                             src/shared/mainloop.h src/shared/mainloop.c
>>> +                             src/shared/mainloop.h src/shared/mainloop.c \
>>> +                             src/shared/mainloop-notify.h \
>>> +                             src/shared/mainloop-notify.c
>>> 
>>> if ELL
>>> src_libshared_ell_la_SOURCES = $(shared_sources) \
>>> diff --git a/src/shared/mainloop-glib.c b/src/shared/mainloop-glib.c
>>> index 8436969bb..9d588e8c5 100644
>>> --- a/src/shared/mainloop-glib.c
>>> +++ b/src/shared/mainloop-glib.c
>>> @@ -36,6 +36,7 @@
>>> #include <glib.h>
>>> 
>>> #include "mainloop.h"
>>> +#include "mainloop-notify.h"
>>> 
>>> static GMainLoop *main_loop;
>>> static int exit_status;
>>> @@ -43,6 +44,7 @@ static int exit_status;
>>> void mainloop_init(void)
>>> {
>>>      main_loop = g_main_loop_new(NULL, FALSE);
>>> +     mainloop_notify_init();
>>> }
>>> 
>>> void mainloop_quit(void)
>>> @@ -70,11 +72,17 @@ int mainloop_run(void)
>>>      if (!main_loop)
>>>              return -EINVAL;
>>> 
>>> +     mainloop_notify("READY=1");
>>> +
>>>      g_main_loop_run(main_loop);
>>> 
>>> +     mainloop_notify("STOPPING=1");
>>> +
>> 
>> I actually think this is too simple. Frankly what we want is some generic code that runs the mainloops and handles the terminations signals and also brings you onto D-Bus. And only then signal READY=1.
> 
> That was the intention, though things like btmon-logger does not need
> to be on D-Bus beside mainloop_run is normally called after D-Bus
> setup since we want to confirm we can claim the name.

I think it is fine to have a version that does not connect to D-Bus, but the name claiming in case of D-Bus based application needs to be handled correctly as well. The background is that we want to start other activities like connecting to mgmt socket etc. only _after_ we successfully claimed the name. Claiming the name is an asynchronous operation (at least in ELL D-Bus) so the mainloop needs to be running.

>> If you look at iwd and wired/dbus.c then I have started something in that direction with dbus_app_run. That needs to be a bit more unified and turned into l_dbus_run or some similar name.
> 
> Right, Im not sure if that applies to our internal g_dbus though but
> for meshd it definitely makes sense.

Our internal gdbus is something that needs to move towards ELL D-Bus really quickly. We have to remove the dependency on libdbus even if we keep gdbus API in place for a while.

>> My thinking really is that the main() function should be just deal with argument parsing and then getting you on the system or session bus. It should not be bothered with all the signal setup or the duplicated code for handling the asynchronous shutdown. And if you have that, then you do a nice integration with NOTIFY_SOCKET.
> 
> I just wanted to tackle READY=1 and STOPPING=1 when the mainloop start
> and stop respectively, those I think make sense regardless of what
> type of service (D-Bus daemon, btproxy, btattach, etc) but perhaps you
> are saying that those things may actually need to be notified in
> different places depending on the service.
> 
> For READY=1 I can see the point if the service does require do to
> something asynchronous before it is considered ready, bluetoothd
> currently don't require that but maybe in ell we are doing something
> different, for STOPPING=1 that only indicates we are starting to
> shutdown so that doesn't rule out doing it asynchronously:
> 
> https://www.freedesktop.org/software/systemd/man/sd_notify.html
> 
> STATUS= is free format and given the example I was assuming if would
> notify things asynchronously if we have to, thus why I created
> mainloop_notify, perhaps we should rename it to
> mainloop_notify_status?
> 
> Watchdog I guess it is pretty safe to do the handling along with the
> mainloop since timeout handling is already done there anyway, anyway
> notifying READY or STOPPING multiple times probably don't make any
> sense, they cannot be undone, we could perhaps have a flag indicating
> if the mainloop shall handle those, maybe via an option like
> -s/--service=[ready, stopping, watchdog] passed to mainloop_init(int
> argc, char *argv[]) that way the user can inform that he wants to run
> the tool as a service and optionally include what states it should
> control (by default it would be all).

The watchdog needs to be done within the mainloop since you have to have timeout handling active.

We can argue about if certain things are useful as a short term quick solution, but in the end we want a proper solution and not just hack it into the codebase. I rather have no systemd integration than a half-baked one.

Regards

Marcel


  reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-26 16:24 Luiz Augusto von Dentz
2018-11-26 16:24 ` [PATCH BlueZ 2/6] share/mainloop: Add watchdog support Luiz Augusto von Dentz
2018-11-26 16:24 ` [PATCH BlueZ 3/6] tool/btmon-logger: Use mainloop_notify instead of sd_notify Luiz Augusto von Dentz
2018-11-26 16:24 ` [PATCH BlueZ 4/6] core: " Luiz Augusto von Dentz
2018-11-26 16:24 ` [PATCH BlueZ 5/6] core: Remove old code related to sd_notify Luiz Augusto von Dentz
2018-11-26 16:24 ` [PATCH BlueZ 6/6] shared/timeout-glib: Check 0 id when removing timeout Luiz Augusto von Dentz
2018-11-26 17:54 ` [PATCH BlueZ 1/6] share/mainloop: Add handling of NOTIFY_SOCKET Marcel Holtmann
2018-11-27  9:51   ` Luiz Augusto von Dentz
2018-11-27 13:30     ` Marcel Holtmann [this message]
2018-11-27 15:19       ` Luiz Augusto von Dentz

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1663DCEA-9B2E-4B2E-BE32-568A7D6CDA3E@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Bluetooth Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-bluetooth/0 linux-bluetooth/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-bluetooth linux-bluetooth/ https://lore.kernel.org/linux-bluetooth \
		linux-bluetooth@vger.kernel.org linux-bluetooth@archiver.kernel.org
	public-inbox-index linux-bluetooth


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-bluetooth


AGPL code for this site: git clone https://public-inbox.org/ public-inbox