From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 21 11:02:59 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 60C60106564A for ; Tue, 21 Apr 2009 11:02:59 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id 226CB8FC0A for ; Tue, 21 Apr 2009 11:02:59 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.t-mobile.co.uk with esmtp (Exim 4.50) id 1LwDkg-0005vo-E4; Tue, 21 Apr 2009 12:02:58 +0100 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22490-10; Tue, 21 Apr 2009 12:02:58 +0100 (BST) Received: from [10.215.108.93] (helo=rya-online.net) by localhost.t-mobile.co.uk with smtp (Exim 4.50) id 1LwDke-0005vb-Pu; Tue, 21 Apr 2009 12:02:58 +0100 Received: (nullmailer pid 2862 invoked by uid 1000); Tue, 21 Apr 2009 11:01:50 -0000 Date: Tue, 21 Apr 2009 12:01:50 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: <1240311202.361300.1366.nullmailer@galant.ukfsn.org> References: <1240311202.361300.1366.nullmailer@galant.ukfsn.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1240311710.547959.2200.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 localhost.t-mobile.co.uk); 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: Tue, 21 Apr 2009 11:02:59 -0000 On Tue, 21 Apr 2009, Iain Hibbert wrote: > > > Bt_devreq() needs to set/restore a filter too > > > > well, maybe. bt_devreq() operates on already opened socket. the > > assumption i'm making here is that application will set appropriate > > filter before calling bt_devreq(). otherwise, application would have > > to always set 'event' field to acceptable value (or zero). i could go > > either way here. just need to document implemented behavior better. > > Mm, its a good point - there are arguments either way (bloat vs guaranteed > success) but I think since the difference between devreq() and devrecv() > is that devreq() handles all the fiddly details for you, I think its worth > doing that aswell.. the bluez hci_send_req() does set the filters btw iain