aboutsummaryrefslogtreecommitdiffstats
path: root/meta-oe/recipes-support/cryptsetup
diff options
context:
space:
mode:
authorAsh Charles <ashcharles@gmail.com>2015-07-30 12:57:19 -0700
committerMartin Jansa <Martin.Jansa@gmail.com>2015-08-18 11:38:04 +0200
commit5cd87e8d6cec23ae23d1dc07ebb0c6b2f65603c3 (patch)
tree63ebd847c01725768f2e93bf1761d155ef4ec5e3 /meta-oe/recipes-support/cryptsetup
parent53da524517e5b1eac8b4edc98f3045dd8f23d7ec (diff)
downloadmeta-openembedded-contrib-5cd87e8d6cec23ae23d1dc07ebb0c6b2f65603c3.tar.gz
meta-openembedded-contrib-5cd87e8d6cec23ae23d1dc07ebb0c6b2f65603c3.tar.bz2
meta-openembedded-contrib-5cd87e8d6cec23ae23d1dc07ebb0c6b2f65603c3.zip
bluez4: Allow systemd to activate bluetooth
The bluetooth.service runs bluetoothd to manage bluetooth devices, if present, in the system. By design, it should be running in either of two cases: 1. A userspace utility (e.g. networkmanager) has made a dbus request for bluetooth services provided by org.bluez. Even without this patch, the bluetooth.service gets run via dbus activation under the systmed aliased name 'dbus-org-bluez.service'. Perfect! 2. A bluetooth device is added to the system. When a bluetooth device is added, udev triggers the special systemd target, bluetooth.target intended to pull in any services needed for bluetooth linked under bluetooth.target.wants. Enable bluetooth.service so it gets linked under bluetooth.target.wants and bluetoothd gets started when a user adds a bluetooth device to the system. To be clear, this isn't forcing bluetooth to be running all the time--- only when either of #1 or #2 are true. Signed-off-by: Ash Charles <ashcharles@gmail.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Diffstat (limited to 'meta-oe/recipes-support/cryptsetup')
0 files changed, 0 insertions, 0 deletions