From owner-freebsd-bluetooth@FreeBSD.ORG Mon May 18 20:32:12 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 93B1E10656C9 for ; Mon, 18 May 2009 20:32:12 +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 236C58FC27 for ; Mon, 18 May 2009 20:32:12 +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 1M69VK-0004OH-RU; Mon, 18 May 2009 20:32:10 +0000 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 16468-10; Mon, 18 May 2009 21:32:10 +0100 (BST) Received: from [10.215.231.136] (helo=rya-online.net) by localhost.t-mobile.co.uk with smtp (Exim 4.50) id 1M69VC-0004Nu-9J; Mon, 18 May 2009 20:32:09 +0000 Received: (nullmailer pid 4726 invoked by uid 1000); Mon, 18 May 2009 20:31:18 -0000 Date: Mon, 18 May 2009 21:31:17 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: References: <1242294653.314348.1748.nullmailer@galant.ukfsn.org> <1242322384.832849.4269.nullmailer@galant.ukfsn.org> <1242328962.345875.22296.nullmailer@galant.ukfsn.org> <1242335731.252131.19040.nullmailer@galant.ukfsn.org> <1242420574.009085.2429.nullmailer@galant.ukfsn.org> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1242678678.137958.4773.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: Mon, 18 May 2009 20:32:17 -0000 On Mon, 18 May 2009, Maksim Yevmenkin wrote: > in any case, state parameter should be checked first before accessing > anything else. i'm guessing we need to define bluetooth device states > independent of implementation. in freebsd we have connected, initialized > and ready = connected+ready states. connected means that device hook is > connected (i.e. device is present). initialized means that we run > initialization sequence (get bd_addr, features, etc.). Mm, I have a bunch of device flags for this situation. I followed the example of a network interface where it must be enabled to work so you can turn it off and save power (for PCMCIA at least it does that, in USB I don't know if there is a way to turn off the power) #define BTF_UP (1<<0) /* unit is up */ #define BTF_RUNNING (1<<1) /* unit is running */ #define BTF_INIT_BDADDR (1<<5) /* waiting for bdaddr */ #define BTF_INIT_BUFFER_SIZE (1<<6) /* waiting for buffer size */ #define BTF_INIT_FEATURES (1<<7) /* waiting for features */ #define BTF_POWER_UP_NOOP (1<<8) /* should wait for No-op on power up */ #define BTF_INIT_COMMANDS (1<<9) /* waiting for supported commands */ #define BTF_INIT (BTF_INIT_BDADDR \ | BTF_INIT_BUFFER_SIZE \ | BTF_INIT_FEATURES \ | BTF_INIT_COMMANDS) but that can be easily converted to other values (btw BlueZ/Linux seems to provide UP/INIT/RUNNING flags) > > Mm, I've fixed bt_devinfo() so it will work for inactive devices, will > > think about the devenum some more. I fixed that now, it just does the best it can - if the device is not enabled you get an unbound socket (but since sending stuff wouldn't work anyway it probably doesn't matter for now :) > > - in bt_devany_cb() you should perhaps make sure that the device is an > > enabled one? > > what does 'enabled' means? I guess it should wait until it finds a 'connected' device then. Otherwise if there are N devices but the first has just been plugged in, such an inquiry may fail. (its one of those edge cases :) { if ((di->state & BTF_UP)) { memcpy(arg, di->devname, HCI_DEVNAME_SIZE); return 1; } return 0; } > > - I'm thinking that bt_devopen() should have an options argument, in order > > to pre-set any options such as TIMESTAMP, DIRECTION etc (even NBIO) > > which will get around the differences in API for that (BlueZ had a weird > > thing with not supporting SOL_SOCKET, SO_TIMESTAMP even though Linux > > does I don't know if they fixed it yet) > > maybe bt_dev{get,set}opts() ? Well, I think a flags/options arg is simpler (very rare would anybody want to change the options during the lifetime of a socket?) Actually, I thought about this some more and found another problem in that bt_devrecv() does not have any way to extract the control messages. > > - in bt_devinquiry() we accept (dev == NULL) to mean any device, should > > that happen in bt_devopen() too? > > we could. > > > - along this line I wonder if it is possible open a promiscuous socket > > (eg as used by hcidump) instead of any particular device? (could be > > dev==NULL I guess, or a PROMISCUOUS option?) I'm not sure how Linux > > works but on NetBSD you must explicitly bind to 00:00:00:00:00:00 to > > get that behaviour (IIRC FreeBSD gives it to you by default but I was > > paranoid :) > > right, in freebsd we just don't bind socket to anything and use filter > to enable all event/packets/etc. this is how we get promiscuous > socket. The thing I didn't like about that is that you might get messages that you think came from your bound device but in fact they came from some other.. > perhaps bt_devopen(NULL) should mean create non-bound socket? Hmm, need to think about it some - again, bt_devrecv() does not have any way to retreive the socket address, so it would need to be declared that the descriptor bt_devopen() returns is a socket handle and using sendto/recvfrom/sendmsg/recvmsg etc is ok in that case. That means that a system that uses a device node instead of a socket for HCI cannot use the API. Perhaps not a problem? I prefer bt_devopen(NULL) to mean 'receive messages from all devices' rather than 'find first device' though.. iain