From: Stefan Seyfried <seife@suse.de>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: linux-bluetooth@vger.kernel.org,
Bastien Nocera <hadess@hadess.net>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: Packaging question
Date: Tue, 23 Sep 2008 20:46:55 +0200 [thread overview]
Message-ID: <48D9399F.4000804@suse.de> (raw)
In-Reply-To: <1221770377.6782.32.camel@californication>
Hi Marcel (and everybody else still listening),
Marcel Holtmann wrote:
> if we go always polling the D-Bus and try to re-connect it is bad, too.
> The solution is to make sure that D-Bus is always running and will never
> die. Everything else is just wrong and will break.
Yes, this was obviously meant as a joke.
This is what I have packaged for now:
- DBus activation for bluetoothd (actually runs the init script)
- udev events run a helper script /lib/udev/bluetooth.sh which basically
consists of:
#!/bin/sh
[ x"$ACTION" != xadd ] && exit 0
touch /var/run/bluetooth-adapter-present
/bin/dbus-send --system --type=method_call \
--print-reply --reply-timeout=1000 \
--dest=org.bluez / org.bluez.hello
- a "bluetooth-coldplug" init script that checks for the existence of the
bluetooth-adapter-present file and runs the "normal" init script (This could
all be put into the normal init script, but I had reasons for splitting
it up).
So the coldplug case will be handled by the second init script, but still the
bluetoothd will only be started if an adapter is present.
Maybe this is kind of a solution until we get DBus started early enough to
make the problem go away.
Another thought: what prevents us from making bluetoothd exit as soon as all
adapters are unplugged? Is it useful for anything without hardware present
(can you alter settings etc)?
Thanks (and have fun in Portland ;)
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)
prev parent reply other threads:[~2008-09-23 18:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-09 14:19 Packaging question Stefan Seyfried
2008-09-10 22:15 ` Marcel Holtmann
2008-09-11 8:40 ` Stefan Seyfried
2008-09-12 16:34 ` Marcel Holtmann
2008-09-18 10:36 ` Stefan Seyfried
2008-09-18 17:16 ` Marcel Holtmann
2008-09-18 17:40 ` Stefan Seyfried
2008-09-18 20:39 ` Marcel Holtmann
2008-09-23 18:46 ` Stefan Seyfried [this message]
Reply instructions:
You may reply publicly 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=48D9399F.4000804@suse.de \
--to=seife@suse.de \
--cc=dwmw2@infradead.org \
--cc=hadess@hadess.net \
--cc=linux-bluetooth@vger.kernel.org \
--cc=marcel@holtmann.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox