From: Szymon Janc <szymon.janc@tieto.com>
To: Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>,
"linux-bluetooth@vger.kernel.org development"
<linux-bluetooth@vger.kernel.org>
Subject: Re: [RFC 0/4] android: Permanent storage support
Date: Wed, 18 Dec 2013 13:39:18 +0100 [thread overview]
Message-ID: <1818951.puoPfgUXXZ@uw000953> (raw)
In-Reply-To: <20131218123111.GE26311@aemeltch-MOBL1>
Hi Andrei,
> Hi Szymon,
>
> On Wed, Dec 18, 2013 at 01:23:40PM +0100, Szymon Janc wrote:
> > Hi Marcel,
> >
> > > Hi Szymon,
> > >
> > > > This is first RFC for storage format for Android daemon.
> > > >
> > > > Some highlights:
> > > > - storage is much simple in format than Linux daemon (no addresses in paths
> > > > or filenames, only 1 adapter support etc)
> > > > - only info that requires persistency over daemon lifetime from Framework
> > > > perspective is stored
> > > > - settings file for adapter config
> > > > - devices file for remote device info (groups are remote devices addresses)
> > > > - Android storage path is /data/misc/bluez (I've decided to not use
> > > > /data/misc/bluetooth to avoid any clashes as there still seems to be
> > > > leftovers available in Android tree eg. there are still references to that
> > > > directory in CTS testcases and init files of Android 4.4)
> > >
> > > I would use /data/misc/bluetooth actually. Especially since the daemon is also called bluetoothd and not bluezd.
> > >
> > > What is the impact on just using /data/misc/bluetooth and see if anything really breaks.
> >
> > OK, this will require proper chown in device init.rc (as it is set to system/system
> > in system/core/rootdir/init.rc), but that would be needed for /data/misc/bluez path
> > anyway...
>
> I wonder can we find place without need to add extra chown... like using
> Bluedroid configuration location?
I would avoid touching bluedroid configs (other than converting storage, but
this is future anyway). And anyone integrating BlueZ into product will need to
modify init.rc anyway so this is not that much of a problem.
--
BR
Szymon Janc
next prev parent reply other threads:[~2013-12-18 12:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-18 11:20 [RFC 0/4] android: Permanent storage support Szymon Janc
2013-12-18 11:20 ` [RFC 1/4] android/bluetooth: Add initial support for permanent storage Szymon Janc
2013-12-18 11:20 ` [RFC 2/4] android/bluetooth: Add initial support for storing device info Szymon Janc
2013-12-18 11:20 ` [RFC 3/4] android/bluetooth: Add support for storing link keys Szymon Janc
2013-12-18 11:21 ` [RFC 4/4] android/bluetooth: Add support for restoring devices from storage Szymon Janc
2013-12-18 11:37 ` [RFC 0/4] android: Permanent storage support Marcel Holtmann
2013-12-18 12:23 ` Szymon Janc
2013-12-18 12:31 ` Andrei Emeltchenko
2013-12-18 12:39 ` Szymon Janc [this message]
2013-12-18 12:35 ` Marcel Holtmann
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=1818951.puoPfgUXXZ@uw000953 \
--to=szymon.janc@tieto.com \
--cc=andrei.emeltchenko.news@gmail.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