Date: Thu, 9 Apr 2009 09:13:24 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: Iain Hibbert <plunky@rya-online.net> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org>, Bruce Simpson <bms@incunabulum.net> Subject: Re: libhci update Message-ID: <bb4a86c70904091013l2d7c2b77ic7f6988e6e7709f2@mail.gmail.com> In-Reply-To: <1239264003.862926.638.nullmailer@galant.ukfsn.org> References: <49D92E26.2030508@incunabulum.net> <bb4a86c70904061358l3983ed51m11265859a833f202@mail.gmail.com> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 9, 2009 at 12:00 AM, Iain Hibbert <plunky@rya-online.net> wrote: > On Thu, 9 Apr 2009, Bruce Simpson wrote: > >> I disagree. I did a fairly in-depth code audit of PyBlueZ, LightBlue, and >> BlueCove. All of them use BlueZ hci_* APIs for a number of things, mostly >> to do with querying properties of the local interfaces. > > I looked briefly at BlueCove the other day and it seems to use a module to > interface with the BlueZ/Linux API but it also has Windows and Mac modules > amongst others. If it needs a FreeBSD or NetBSD module then that doesn't > seem so difficult? right, that is something i kinda wondering too. of course, i have no idea how hard it would be to plug new bluetooth module into bluecove. perhaps cost of adding the new bluetooth module more than implementing something that looks like bluez? >> The problem is that the horse has already left the cart. > > That happened many years ago when Microsoft was the leader in the > marketplace. If you want to stay with the horse, use Windows. the real question is: do we really want to follow the horse? :) personally, i think that we should keep an eye on bluez etc. to see where its going, but blindly follow it, is not something we want to do, imo, having said that, we have to recognize the fact that there is lots of code that is bluez specific. so, how about we separate flies from meatballs, and, meet halfway: 1) we put bsd-style bluetooth api and make sure it is shared with as many bsd's (and possibly other os's) as possible. i personally would like to continue to work with Iain and get his input. this api is going into the base system and will be bsd-licensed. obviously, we will keep an eye on bluez while designing and implementing bsd bluetooth api. 2) to ensure compatibility with bluez we create a separate library and put it into the ports/ collection. it can even use original libhci headers and re-use original libhci code if needed. missing/different parts will have to be re-implemented in terms of bsd bluetooth api. this way it would probably be easier to play catch up game with bluez and it will be less of pain for folks who use bsd bluetooth api. basically, if you choose bluez api be prepared to change your code every time bluez folks change something. >> There have been books published on how to use Bluetooth from Java and >> other higher level languages than C. It seems unreasonable, in my view, >> to expect folk developing applications in a commercial model, to have to >> adapt their code for BSD targets beyond say 2 or 3 ifdef's. > > so write a module that interfaces (for example) the Java (BlueCove?) API > to the FreeBSD OS layer. Its not that different from the BlueZ/Linux API > and you can probably just do some copy and paste work. Thats how the GPL > world works. Yes, you will not be able to integrate that work directly > into FreeBSD but then I doubt a Java interface is ever going to be > accepted into base anyway. Donate it to BlueCove. well, it depends on how hard it is to add such module. i can certainly see and understand yours and Bruce's point. >> I realize this might be an inelegant approach, but it's based on >> observation of harsh commercial realities. > > If its commercial, get those companies to contribute some BSD code. oh, well, sometimes it is not as easy as it sounds. >> Thanks for this. I would far rather not introduce a runtime or link-time >> dependency on -lnetgraph if I can possibly avoid it. I'll digest further >> and try to see if this can be incorporated. > > But I thought, on FreeBSD the whole bluetooth stack is netgraph based..? yes, but in userspace you almost never need to use anything netgraph related. almost everything can be done through sockets. > My stance on the compatibility issue is that there are some things in the > BlueZ/Linux C API (the major thing being 'devid' to address the radio) > that are tied to the actual OS support and are unsupportable unless you > provide exactly the same API in the OS. But, OS support is way too low > level for an application to deal (with as you say), and a higher level API > is needed that does not contain such specifics. mostly agreed. its not really that bad with devid. we could invent some "static" mapping between devname and devid. Bruce used id's from netgraph, i used (dev_type|unit_no) for mapping, and, i'm sure, you can find something as simple as this. it really does not matter that much as long as the application that uses devid's is not making any assumptions about them (for example does not hardwire devid 0 - or whatever - anywhere to talk to the first available bluetooth device). > The BlueZ guys are, I think, working on a dbus API that will be used by > GNOME and KDE and hopefully it won't be tied to the Linux OS API so > closely, so that we can write dbus modules and have applications just work > on our OS. I have not been providing any input or review of that API > though, it would be good if somebody would step up and point out where the > API is tied too closely to the Linux OS interface and get them to make it > a bit more generic. right, and that is a very good point. that is something that i have to deal with every day at $realjob. things in linux world change very rapidly. from commercial point of view it is very annoying. its not that uncommon that entire subsystems are being thrown away and re-written from scratch without too much consideration. that is why i think having a separate libhci/ port is making more sense here. >> I looked at the Bluetooth specs and I can see that the inquiry sequence >> doesn't hog all of the radio spectrum in use, but the implementation on >> the CSR dongles won't raise any other events whilst the inquiry is in >> progress. > > Is this purely a CSR problem? My laptop has a Broadcom chip in and I > notice that it can make multiple connections concurrently in that on > bootup, it connects to both my mouse and keyboard by itself sometimes - > the CSR dongle I used previously would connect to the keyboard fine but > always fail the second connect with "Command Disallowed". So much so that > I thought perhaps about serialising connection attempts in the kernel. that's right, some dongles would not do 2 or more create_connection commands at the same time. i do not think specification actually mandates this, so it is probably vendor/chip/firmware specific. as far as periodic inquiry goes, its probably not the rf spectrum hogging. its probably related to the way hardware and/or link manager is implemented, i.e. from specification <quote> A unit that wants to discover other Bluetooth units enters an inquiry substate. In this substate, it continuously transmits the inquiry message (which is the ID packet, see Section 4.4.1.1 on page 55) at different hop frequencies. The inquiry hop sequence is always derived from the LAP of the GIAC. Thus, even when DIACs are used, the applied hopping sequence is generated from the GIAC LAP. </quote> the key thing is that device has to continuously transmits the inquiry message at different hop frequencies. at the same time the same device may participate in another connection (which may require hopping as well). > I've never looked at periodic inquiry though.. me too. but now i'm interested :) thanks max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70904091013l2d7c2b77ic7f6988e6e7709f2>