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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
+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)
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel