From owner-freebsd-bluetooth@FreeBSD.ORG Thu May 14 17:38:04 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E78E6106564A for ; Thu, 14 May 2009 17:38:03 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp01.one2one.net (smtp01.one2one.net [149.254.200.196]) by mx1.freebsd.org (Postfix) with ESMTP id 78DAA8FC1C for ; Thu, 14 May 2009 17:38:03 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1M4esc-0007V9-00; Thu, 14 May 2009 17:38:02 +0000 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28782-05; Thu, 14 May 2009 18:38:01 +0100 (BST) Received: from [10.216.51.64] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1M4eof-0007Dj-8e; Thu, 14 May 2009 17:34:00 +0000 Received: (nullmailer pid 11196 invoked by uid 1000); Thu, 14 May 2009 17:33:04 -0000 Date: Thu, 14 May 2009 18:33:04 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: References: <1240311202.361300.1366.nullmailer@galant.ukfsn.org> <1240352254.082638.416.nullmailer@galant.ukfsn.org> <1240386569.369073.696.nullmailer@galant.ukfsn.org> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1242322384.832849.4269.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on smtpbarns01); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 17:38:04 -0000 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