All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Alexander Holler <holler@ahsoftware.de>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH] bluetoothd: add option to automatically power on the first adapter found
Date: Sun, 26 Apr 2015 21:40:29 -0700	[thread overview]
Message-ID: <BBD84100-9DE9-4A7A-8DA3-4DD8B3458F25@holtmann.org> (raw)
In-Reply-To: <553B6BC5.4060407@ahsoftware.de>

Hi Alexander,

>>> Your race power on vs keys and known devices programmed into the
>>> kernel. It needs to be done in the right order.
>> 
>> Hmm, I still seem to function, no sign of races, besides that I'm
>> happily working without a Linux kernel.
>> 
>> But in regard to the patch. Maybe. No idea. It works for me (tm) and is
>> faster and more reliable here than other stuff.
> 
> To pick up that thread again, if you want that I remove a race in that patch I don't see by looking at it, you have to be a bit more verbose about the race.

it is pretty simple, you want to configure the list of known devices and its keys before you turn on your device for general operation. If you don't do that, you have a race condition.

> For me it currently reads like you're more talking about an existing problem in the kernel. If the kernel doesn't like it that a bt-device will be turned on before something like keys and known devices have been setup, then the kernel should throw an error back to userspace.

The kernel is not enforcing policy. We can not require to have keys loaded first. There might be no keys or you want to use the Bluetooth subsystem for something else. The kernel mgmt interface provides a flexible way into the general procedures that Bluetooth requires. With bluetoothd we enforce profiles and other behaviors to be consistent. That is not the kernel's job.

And even if we wanted to restrict this heavily, we can not easily do that without potentially breaking existing userspace.

> But that's just an assumption from me, I haven't read through all the source in bluetoothd or the kernel, but instead just turned on a knob like it would be turned on by issuing "power on" in bluetoothctl.

With bluetoothctl you talk over the D-Bus interface to bluetoothd. So when you turn power on there, then it is ensured that everything happens in the right order. That is what bluetoothd enforces. It is not the kernels job to do that.

Regards

Marcel


  reply	other threads:[~2015-04-27  4:40 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-10 16:57 [PATCH] bluetoothd: add option to automatically power on the first adapter found Alexander Holler
2015-04-10 17:10 ` Marcel Holtmann
2015-04-10 17:15   ` Alexander Holler
2015-04-11  4:06     ` Alexander Holler
2015-04-11  5:07       ` Alexander Holler
2015-04-11 16:48         ` Alexander Holler
2015-04-11 17:55           ` Marcel Holtmann
2015-04-12  9:23             ` Alexander Holler
2015-04-12 18:50               ` Marcel Holtmann
2015-04-13  9:10                 ` Alexander Holler
2015-04-13 14:32                   ` Marcel Holtmann
2015-04-13 19:08                     ` Alexander Holler
2015-04-13 20:22                       ` Marcel Holtmann
2015-04-14  8:33                         ` Alexander Holler
2015-04-14 13:50                           ` Marcel Holtmann
2015-04-14 14:14                             ` Szymon Janc
2015-04-14 15:56                               ` Szymon Janc
2015-04-15 17:59                             ` Alexander Holler
2015-04-25 10:26                               ` Alexander Holler
2015-04-27  4:40                                 ` Marcel Holtmann [this message]
2015-04-27  9:11                                   ` Alexander Holler
2015-04-27 18:53                                     ` Marcel Holtmann
2015-04-27 20:36                                       ` Alexander Holler
2015-04-10 17:15   ` Szymon Janc

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=BBD84100-9DE9-4A7A-8DA3-4DD8B3458F25@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=holler@ahsoftware.de \
    --cc=linux-bluetooth@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.