[Bluez-devel] Should hcid wait for dbus daemon?

[Bluez-devel] Should hcid wait for dbus daemon?

[Daniel Gollub]

Hi,

the hcid daemon aborts when there is no dbus daemon running. What about 
enhancing hcid to handle the case that the dbus daemon get started after 
hcid. I know there are might be not many use cases. But at least i know one 
case ;)

To avoid that there is another "unneeded" service running, i want to call only 
the bluetooth init scripts when there is a bluetooth device plugged in. This 
is done by a simple udev rule, which calls the bluetooth init script when the 
device got plugged in.

So there is no need to insserv or do any other stuff like running YaST or 
something like that. Just turn on the bluetooth device or plug it in and the 
bluetooth service get started by udev.

The only problem is during boot. udev get started before the dbus daemon, and 
will trigger the udev rule which calls the bluetooth init script. Then hcid 
will fail because the dbus daemon isn't started in this early stage of boot.

If the hcid would wait for the dbus daemon this wouldn't be a problem. At 
least hcid can handle a dbus daemon restart, maybe we can enhance this.

I know this can be also done in the bluetooth init script, but maybe someone 
else insist on this enhancement.

best regards,
Daniel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Should hcid wait for dbus daemon?

[Johan Hedberg]

Hi Daniel,

On Mon, Jan 08, 2007, Daniel Gollub wrote:
> If the hcid would wait for the dbus daemon this wouldn't be a problem. At 
> least hcid can handle a dbus daemon restart, maybe we can enhance this.

Sounds like a useful feature. It should be quite simple to implement too 
since most of the required code already exists due to the dbus restart 
detection support. Feel free to provide a patch for it :)

Johan

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Should hcid wait for dbus daemon?

[Luca Capello]

[-- Attachment #1.1: Type: text/plain, Size: 1380 bytes --]

Hello!

NB, I'm not deeply involved in bluetooth neither dbus development,
just a "power user".  If my thoughts are wrong, just discard them.

On Mon, 08 Jan 2007 19:47:01 +0100, Johan Hedberg wrote:
> On Mon, Jan 08, 2007, Daniel Gollub wrote:
>> If the hcid would wait for the dbus daemon this wouldn't be a
>> problem. At least hcid can handle a dbus daemon restart, maybe we
>> can enhance this.
>
> Sounds like a useful feature.

Shouldn't be the contrary?  I mean, on a clean Debian etch, every
dbus-dependent service is started by dbus:
=====
root@gismo:/home/luca# ls -l /etc/dbus-1/eventd.d/
total 16
-rwxr-xr-x 1 root root 1901 2006-11-11 15:38 20hal
-rwxr-xr-x 1 root root 1091 2006-10-24 15:22 24dhcdbd
lrwxrwxrwx 1 root root   25 2007-01-07 21:53 25avahi-daemon -> \
 ../../init.d/avahi-daemon
-rwxr-xr-x 1 root root 1766 2006-11-30 22:22 25NetworkManager
-rwxr-xr-x 1 root root 1684 2006-11-30 22:22 26NetworkManagerDispatcher

root@gismo:/home/luca# invoke-rc.d dbus start
Starting system message bus: dbus.
Starting Hardware abstraction layer: hald.
Starting DHCP D-Bus daemon: dhcdbd.
Starting network connection manager: NetworkManager.
Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon.
Starting network events dispatcher: NetworkManagerDispatcher.

root@gismo:/home/luca#
=====

Just my 0.02€...

Thx, bye,
Gismo / Luca

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Should hcid wait for dbus daemon?

[Daniel Gollub]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

On Monday 08 January 2007 19:47, Johan Hedberg wrote:
> Sounds like a useful feature. It should be quite simple to implement too
> since most of the required code already exists due to the dbus restart
> detection support. Feel free to provide a patch for it :)
How often should the daemons try to connect? Or infinitely?
If not infinitely, then configurable by command line parameter or fixed?

Attachted is a _simple_ proof of concept patch which . It retries every 5 
seconds. After #12 unsuccessfully dbus connect, it gives up and abort (as 
before).

Daniel

[-- Attachment #2: bluez-utils-dbus-retry.diff --]
[-- Type: text/x-diff, Size: 1157 bytes --]

Index: common/dbus.c
===================================================================
RCS file: /cvsroot/bluez/utils/common/dbus.c,v
retrieving revision 1.2
diff -u -p -r1.2 dbus.c
--- common/dbus.c	13 Nov 2006 07:58:40 -0000	1.2
+++ common/dbus.c	8 Jan 2007 22:52:18 -0000
@@ -39,6 +39,7 @@
 #include "list.h"
 
 #define DISPATCH_TIMEOUT	0
+#define MAX_DBUS_RETRY		12
 
 static int name_listener_initialized = 0;
 
@@ -485,13 +486,27 @@ static void dispatch_status_cb(DBusConne
 
 DBusConnection *init_dbus(const char *name, void (*disconnect_cb)(void *), void *user_data)
 {
+	int retry = 0;
 	struct disconnect_data *dc_data;
 	DBusConnection *conn;
 	DBusError err;
 
 	dbus_error_init(&err);
 
-	conn = dbus_bus_get(DBUS_BUS_SYSTEM, &err);
+	do {
+		if (dbus_error_is_set(&err))
+			dbus_error_free(&err);
+
+		conn = dbus_bus_get(DBUS_BUS_SYSTEM, &err);
+		if (conn)
+			break;
+
+		if (!retry)
+			info("Can't connect to DBUS. Will retry %i times.", MAX_DBUS_RETRY);
+
+		usleep(5000000);
+		retry++;
+	} while (!conn && retry < MAX_DBUS_RETRY);
 
 	if (dbus_error_is_set(&err)) {
 		error("Can't connect to system message bus: %s", err.message);

[-- Attachment #3: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Should hcid wait for dbus daemon?

[Daniel Gollub]

T24gVHVlc2RheSAwOSBKYW51YXJ5IDIwMDcgMDA6MzEsIEx1Y2EgQ2FwZWxsbyB3cm90ZToKPiBT
aG91bGRuJ3QgYmUgdGhlIGNvbnRyYXJ5PyDCoEkgbWVhbiwgb24gYSBjbGVhbiBEZWJpYW4gZXRj
aCwgZXZlcnkKPiBkYnVzLWRlcGVuZGVudCBzZXJ2aWNlIGlzIHN0YXJ0ZWQgYnkgZGJ1czoKQnV0
IHRoZW4gaGNpZCBnZXRzIGV2ZXJ5dGltZSBzdGFydGVkLCBldmVuIGlmIHRoZXJlIGlzIG5vIGJs
dWV0b290aCBkb25nbGUgCmNvbm5lY3RlZC4gSSBndWVzcyB0aGVyZSBhcmUgc2V2ZXJhbCBwZW9w
bGUgd2hpY2ggb25seSBjb25uZWN0IHRoZWlyIApibHVldG9vdGggZG9uZ2xlIG9uY2UgYSB3ZWVr
LiBPciBtYXliZSBvbmx5IG9uY2UgYXQgYWxsIGFuZCBuZXZlciBhZ2Fpbi4KVGhpcyB3YXMgdGhl
IG1haW4gaW50ZW50aW9uIHRvIHJ1biBvbmx5IHRoZSBibHVldG9vdGggZGFlbW9ucyBpZiBhbnkg
ZGV2aWNlIGlzIApjb25uZWN0ZWQuCgpEYW5pZWwKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KVGFrZSBTdXJ2
ZXlzLiBFYXJuIENhc2guIEluZmx1ZW5jZSB0aGUgRnV0dXJlIG9mIElUCkpvaW4gU291cmNlRm9y
Z2UubmV0J3MgVGVjaHNheSBwYW5lbCBhbmQgeW91J2xsIGdldCB0aGUgY2hhbmNlIHRvIHNoYXJl
IHlvdXIKb3BpbmlvbnMgb24gSVQgJiBidXNpbmVzcyB0b3BpY3MgdGhyb3VnaCBicmllZiBzdXJ2
ZXlzIC0gYW5kIGVhcm4gY2FzaApodHRwOi8vd3d3LnRlY2hzYXkuY29tL2RlZmF1bHQucGhwP3Bh
Z2U9am9pbi5waHAmcD1zb3VyY2Vmb3JnZSZDSUQ9REVWREVWCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fCkJsdWV6LWRldmVsIG1haWxpbmcgbGlzdApCbHVl
ei1kZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5u
ZXQvbGlzdHMvbGlzdGluZm8vYmx1ZXotZGV2ZWwK

Re: [Bluez-devel] Should hcid wait for dbus daemon?

[Stefan Seyfried]

Hi Luca,

On Tue, Jan 09, 2007 at 12:31:12AM +0100, Luca Capello wrote:

> NB, I'm not deeply involved in bluetooth neither dbus development,
> just a "power user".  If my thoughts are wrong, just discard them.

They are not wrong, it is just a different use case :-)

> Shouldn't be the contrary?  I mean, on a clean Debian etch, every
> dbus-dependent service is started by dbus:
 =

> root@gismo:/home/luca# invoke-rc.d dbus start
> Starting system message bus: dbus.
> Starting Hardware abstraction layer: hald.
> Starting DHCP D-Bus daemon: dhcdbd.
> Starting network connection manager: NetworkManager.
> Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon.
> Starting network events dispatcher: NetworkManagerDispatcher.
> =

> root@gismo:/home/luca#

This is about the same if i statically enable the bluetooth service
on a SUSE machine. But i would like to avoid that (no need to run
hcid on a machine that will never see a BT device). At the same time,
i like to have it "just work", without the user needing to configure
it. So i start the bluetooth services via udev, when a BT device
is connected.

This works very well once the machine is up and running. If the device
is connected during boot, it is different, because the udev "coldplug"
happens before most of the services are started.

I hope this clears up my (and Daniels) intentions :-)

Have fun
-- =

Stefan Seyfried
QA / R&D Team Mobile Devices        |              "Any ideas, John?"
SUSE LINUX Products GmbH, N=FCrnberg  | "Well, surrounding them's out." =


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Should hcid wait for dbus daemon?

[Stefan Seyfried]

Ping! :-)

Any opinions on that approach? This fixes the hotplug issue for our users,
but i want to stay as close to upstream as possible :-)

On Tue, Jan 09, 2007 at 12:41:53AM +0100, Daniel Gollub wrote:
> On Monday 08 January 2007 19:47, Johan Hedberg wrote:
> > Sounds like a useful feature. It should be quite simple to implement too
> > since most of the required code already exists due to the dbus restart
> > detection support. Feel free to provide a patch for it :)
> How often should the daemons try to connect? Or infinitely?
> If not infinitely, then configurable by command line parameter or fixed?
> =

> Attachted is a _simple_ proof of concept patch which . It retries every 5 =

> seconds. After #12 unsuccessfully dbus connect, it gives up and abort (as =

> before).
> =

> Daniel

> Index: common/dbus.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/bluez/utils/common/dbus.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 dbus.c
> --- common/dbus.c	13 Nov 2006 07:58:40 -0000	1.2
> +++ common/dbus.c	8 Jan 2007 22:52:18 -0000
> @@ -39,6 +39,7 @@
>  #include "list.h"
>  =

>  #define DISPATCH_TIMEOUT	0
> +#define MAX_DBUS_RETRY		12
>  =

>  static int name_listener_initialized =3D 0;
>  =

> @@ -485,13 +486,27 @@ static void dispatch_status_cb(DBusConne
>  =

>  DBusConnection *init_dbus(const char *name, void (*disconnect_cb)(void *=
), void *user_data)
>  {
> +	int retry =3D 0;
>  	struct disconnect_data *dc_data;
>  	DBusConnection *conn;
>  	DBusError err;
>  =

>  	dbus_error_init(&err);
>  =

> -	conn =3D dbus_bus_get(DBUS_BUS_SYSTEM, &err);
> +	do {
> +		if (dbus_error_is_set(&err))
> +			dbus_error_free(&err);
> +
> +		conn =3D dbus_bus_get(DBUS_BUS_SYSTEM, &err);
> +		if (conn)
> +			break;
> +
> +		if (!retry)
> +			info("Can't connect to DBUS. Will retry %i times.", MAX_DBUS_RETRY);
> +
> +		usleep(5000000);

here, a
		sleep(5);
might be easier to read :-)

> +		retry++;
> +	} while (!conn && retry < MAX_DBUS_RETRY);
>  =

>  	if (dbus_error_is_set(&err)) {
>  		error("Can't connect to system message bus: %s", err.message);
-- =

Stefan Seyfried
QA / R&D Team Mobile Devices        |              "Any ideas, John?"
SUSE LINUX Products GmbH, N=FCrnberg  | "Well, surrounding them's out." =


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Should hcid wait for dbus daemon?

[Andrey Rahmatullin]

[-- Attachment #1.1: Type: text/plain, Size: 140 bytes --]

+1, we in ALT Linux use exactly the same scheme for launching hcid and we
also want to fix this issue.

-- 
WBR, wRAR (ALT Linux Team)

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Should hcid wait for dbus daemon?

[Marcel Holtmann]

Hi Daniel,

> the hcid daemon aborts when there is no dbus daemon running. What about 
> enhancing hcid to handle the case that the dbus daemon get started after 
> hcid. I know there are might be not many use cases. But at least i know one 
> case ;)
> 
> To avoid that there is another "unneeded" service running, i want to call only 
> the bluetooth init scripts when there is a bluetooth device plugged in. This 
> is done by a simple udev rule, which calls the bluetooth init script when the 
> device got plugged in.
> 
> So there is no need to insserv or do any other stuff like running YaST or 
> something like that. Just turn on the bluetooth device or plug it in and the 
> bluetooth service get started by udev.
> 
> The only problem is during boot. udev get started before the dbus daemon, and 
> will trigger the udev rule which calls the bluetooth init script. Then hcid 
> will fail because the dbus daemon isn't started in this early stage of boot.
> 
> If the hcid would wait for the dbus daemon this wouldn't be a problem. At 
> least hcid can handle a dbus daemon restart, maybe we can enhance this.
> 
> I know this can be also done in the bluetooth init script, but maybe someone 
> else insist on this enhancement.

I don't think that it is a good idea to have udev start daemons. My
understanding is that udev is for creating device nodes or init
hardware. In case of BlueZ it must start a number of daemons to have a
fully working Bluetooth setup. This task is better done by systems like
upstart which handle dependencies.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel