Date: Thu, 14 May 2009 18:33:04 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: freebsd-bluetooth@freebsd.org Subject: Re: libhci update Message-ID: <1242322384.832849.4269.nullmailer@galant.ukfsn.org> In-Reply-To: <bb4a86c70905140926n488cb2b5x5f5530e01d70bd66@mail.gmail.com> References: <E1Lv5La-00058x-HH@smtpbarns01> <bb4a86c70904201053y1a04d76el336432d3e1a23576@mail.gmail.com> <1240311202.361300.1366.nullmailer@galant.ukfsn.org> <bb4a86c70904210959w6de5e808h9f85ee2bb1995dbf@mail.gmail.com> <1240352254.082638.416.nullmailer@galant.ukfsn.org> <bb4a86c70904211651m6127745ao9d4f26c91e428994@mail.gmail.com> <1240386569.369073.696.nullmailer@galant.ukfsn.org> <bb4a86c70904220909j5d047ce6x6260bd2e87b5b7bd@mail.gmail.com> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> <bb4a86c70905140926n488cb2b5x5f5530e01d70bd66@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 14 May 2009, Maksim Yevmenkin wrote:
> Iain,
>
> >> thanks for the review. i committed it to -head.
> >
> > Hi Max, I'm in progress of translating for NetBSD and in bt_devinquiry() I
> > see
> >
> > if (ii == NULL) {
> > errno = EINVAL;
> > return (-1);
> > }
> >
> > but I think this test might be bogus? manpage implies that the caller
> > provides a buffer but we allocate one..
>
> no, the test is correct. yes, we allocate buffer internally, but we
> need to return pointer to the buffer back to the caller. so, ii is
> basically ii is struct bt_devinquiry **. perhaps language in the man
> page is not clear enough?
Ah yes, my bad. I haven't properly looked at the manpage yet (I saw a
spelling mistake earlier but I didn't note it :), will examine it in
detail later. I'm trying to think of another function that does similar to
copy the language from, perhaps asprintf()?
btw do you know what devinfo->role_switch_info might contain? I have
link_policy_info which presumably contains the following flags
/* Link policy settings */
#define HCI_LINK_POLICY_DISABLE_ALL_LM_MODES 0x0000
#define HCI_LINK_POLICY_ENABLE_ROLE_SWITCH 0x0001 /* Master/Slave switch */
#define HCI_LINK_POLICY_ENABLE_HOLD_MODE 0x0002
#define HCI_LINK_POLICY_ENABLE_SNIFF_MODE 0x0004
#define HCI_LINK_POLICY_ENABLE_PARK_MODE 0x0008
/* 0x0010 - 0x8000 - reserved for future use */
but I'm not sure what to put in role_switch_info? (for now, 0 :)
> > also, I'm not sure that the timeout is handled right; the bt_devrecv()
> > uses the complete timeout each time but the time endpoint might need to be
> > calculated so that time-to-end can be used?
>
> well, yes. bt_devrecv() was envisioned as "one-shot" call. the only
> case, imo, where it can restart internally with the same timeout is
> when select is interrupted by a signal.
I think the timeout should probably act the same way as in bt_devreq(),
but I thought there could be close calls at the end because of the integer
arithmetic.
> > Also I'm wondering what to do in the case bt_devrecv() does actually time
> > out - what can it mean and should we [attempt to] cancel the inquiry?
>
> ahh, but in case of bt_devinquiry() it probably does not matter that
> much because inquiry itself is limited by the "length" parameter. so
> we have to receive something back from the device. i was thinking to
> pass -1 as timeout to bt_devrecv() in this particular case, but
> decided not to do it (try harder to exit the bt_devinquiry()).
mm, -1 is tempting but I think its better to error timeout even if the
device is left in a weird state. At least the user won't be left waiting..
I'll continue to work on it because a successful exit must wait until the
device has exited inquiry mode. (I noticed that you can't do things like
get-remote-name when still in inquiry mode, at least on some devices)
iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1242322384.832849.4269.nullmailer>