Re: [PATCH] Add on demand functionality to bluetooth init script

[Stefan Seyfried <seife@suse.de>]

On Fri, Jun 05, 2009 at 05:48:26PM +0200, Marcel Holtmann wrote:

> first of all the question from Stefan needs to be handled on how we
> handle the case for udev event before D-Bus system daemon is started.
> 
> Personally I think having an extra init script style for this makes no
> sense and just adds complexity in the start/stop process of the daemon.
> 
> I might prefer if we add special bluetoothd --udev={start,stop} handling
> to it (including polling code for D-Bus system daemon availability).

I actually solved it like this (no, I'm not proud of it, but it works):

* instead of calling "/etc/init.d/bluetooth condstart" from udev, I call
  a bluetooth.sh which basically does:

  mkdir /dev/shm/bluetooth-adapter-present # this is just a marker
  /bin/dbus-send --system --type=method_call --print-reply \
	--reply-timeout=1000 --dest=org.bluez / org.bluez.hello

  If D-Bus is already up (adapter hotplug), then the dbus-send activates
  bluetoothd via dbus-activation.

* I have a second, trivial init script which is always enabled and runs
  at the end of the boot process (after D-Bus start, that is) and which
  just does

  [ -x /dev/shm/bluetooth-adapter-present ] && \
	/etc/init.d/bluetooth start

  This handles the "adapter was plugged in before D-Bus was ready" case.

It's not particularly pretty, and I do not want to suggest that this is
a correct solution, but it solved the problem nicely for me.

Regards,

	Stefan
-- 
Stefan Seyfried
R&D Team Mobile Devices            |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." 

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)