From: Johan Hedberg <johan.hedberg@gmail.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Frederic Danis <frederic.danis@intel.com>,
"linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>
Subject: Re: [RFC] Convert storage to use per-remote device directories
Date: Mon, 1 Oct 2012 11:16:21 +0300 [thread overview]
Message-ID: <20121001081621.GA20326@x220> (raw)
In-Reply-To: <1348842803.13371.25.camel@aeonflux>
Hi Marcel,
On Fri, Sep 28, 2012, Marcel Holtmann wrote:
> > Here is my proposal for new storage directory structure using ini-file
> > format.
> >
> > Each adapter directory (/var/lib/bluetooth/<adapter address>/) will
> > contain a config file for the local adapter and one directory per remote
> > device.
> > The adapter config file just need to be converted to ini-file format
> > with only 1 group called [adapter].
> >
> > Each of remote device directories' name will be based on remote device
> > address and address type (address#type).
> > This directory will contain a config file with remote device infos and a
> > linkkey file.
> > Remote device config file will include a [device] group with general
> > device infos (name, alias, profiles or services list, ...), and groups
> > named by profile uuid (or service uuid) with related infos.
> >
> > So the directory structure should be:
> > /var/lib/bluetooth/<adapter address>/
> > ./config
> > ./<remote device address#type>/
> > ./config
> > ./linkkey
> > ./<remote device address#type>/
> > ./config
> > ./linkkey
> > ...
>
> why do we care about the address type here? Can we actually have a
> different link key for BR/EDR and for LE? Right now it is really only
> one choice on how to use that remote device. If it is dual-mode, then we
> use BR/EDR and if it is single-mode we use LE.
I think the idea here was to avoid potential (though unlikely)
collisions of a static random address of device A and a public address
of device B. However, thinking about it, is such a collision actually
possible considering that the two most significant bits of a static
random address must be 1. I'd imagine that the Core spec. writers would
have tried to make sure that this will not clash with any OUI's.
In any case we do at least need to have the address type info somewhere
in the device-specific directory so bluetoothd knows how to connect to
the device.
Johan
prev parent reply other threads:[~2012-10-01 8:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-27 9:59 [RFC] Convert storage to use per-remote device directories Frederic Danis
2012-09-28 9:37 ` Johan Hedberg
2012-09-28 12:36 ` Frederic Danis
2012-09-28 10:56 ` Anderson Lizardo
2012-09-28 13:12 ` Frederic Danis
2012-09-28 14:04 ` Anderson Lizardo
2012-10-01 8:30 ` Johan Hedberg
2012-09-28 14:33 ` Marcel Holtmann
2012-10-01 8:16 ` Johan Hedberg [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=20121001081621.GA20326@x220 \
--to=johan.hedberg@gmail.com \
--cc=frederic.danis@intel.com \
--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;
as well as URLs for NNTP newsgroup(s).