From: Johan Hedberg <johan.hedberg@gmail.com>
To: Arik Nemtsov <arik@wizery.com>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH v4 1/6] att: add remote btd_device to ATT read/write callbacks
Date: Wed, 21 Mar 2012 09:43:34 -0300 [thread overview]
Message-ID: <20120321124334.GA8888@x220> (raw)
In-Reply-To: <CA+XVXffkOx_m11LouHnxqJp4AWNS9jLuUM-JcjgnEi68XWRs2w@mail.gmail.com>
Hi Arik,
On Tue, Mar 20, 2012, Arik Nemtsov wrote:
> On Tue, Mar 20, 2012 at 19:36, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> > Hi Arik,
> >
> > On Mon, Mar 19, 2012, Arik Nemtsov wrote:
> >> - uint8_t (*read_cb)(struct attribute *a, gpointer user_data);
> >> - uint8_t (*write_cb)(struct attribute *a, gpointer user_data);
> >> + uint8_t (*read_cb)(struct attribute *a, gpointer user_data,
> >> + gpointer device);
> >> + uint8_t (*write_cb)(struct attribute *a, gpointer user_data,
> >> + gpointer device);
> >
> > Why is device a gpointer and not a struct btd_device *?
>
> Well att.h is a self contained include file (also used in gatttool for
> example).
How then could any of these callbacks receive a pointer to btd_device
when used in gatttool? And if they're not used in gatttool it seems like
some refactoring may be in place here (i.e. there should be be a
library-like .h file and then something else for stuff which is bound to
bluetoothd-internal constructs (like btd_device).
> That means there would have to be at least a forward declaration for
> btd_device. If we go down that road, it gets tricky, since we depend
> on the include order of att.h and device.h. This can maybe be solved
> with ifdef tricks, but I thinking leaving att.h self contained is the
> better option here.
In general we try to avoid double-include protections in internal .h
files. The convention is that .c files just have to include the
dependencies.
Johan
next prev parent reply other threads:[~2012-03-21 12:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-19 8:58 [PATCH v4 0/6] Implement ProximityReporter profiles Arik Nemtsov
2012-03-19 8:58 ` [PATCH v4 1/6] att: add remote btd_device to ATT read/write callbacks Arik Nemtsov
2012-03-20 17:36 ` Johan Hedberg
2012-03-20 17:48 ` Arik Nemtsov
2012-03-21 12:43 ` Johan Hedberg [this message]
2012-03-21 21:01 ` Arik Nemtsov
2012-03-19 8:58 ` [PATCH v4 2/6] proximity: reporter: save global D-Bus connection Arik Nemtsov
2012-03-19 8:58 ` [PATCH v4 3/6] proximity: reporter: move definitions to .h and add util function Arik Nemtsov
2012-03-19 8:58 ` [PATCH v4 4/6] proximity: link loss: implement link loss server Arik Nemtsov
2012-03-19 8:58 ` [PATCH v4 5/6] proximity: immediate alert: implement immediate alert server Arik Nemtsov
2012-03-19 8:58 ` [PATCH v4 6/6] proximity: reporter: implement D-Bus API Arik Nemtsov
2012-03-20 16:15 ` Fwd: [PATCH v4 0/6] Implement ProximityReporter profiles Arik Nemtsov
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=20120321124334.GA8888@x220 \
--to=johan.hedberg@gmail.com \
--cc=arik@wizery.com \
--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.