Date: Thu, 09 Apr 2009 20:36:15 +0100 From: Bruce Simpson <bms@incunabulum.net> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org>, "alexei@raylab.com" <alexei@raylab.com> Subject: Re: libhci update Message-ID: <49DE4E2F.2000805@incunabulum.net> In-Reply-To: <bb4a86c70904091013l2d7c2b77ic7f6988e6e7709f2@mail.gmail.com> References: <49D92E26.2030508@incunabulum.net> <bb4a86c70904061358l3983ed51m11265859a833f202@mail.gmail.com> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <bb4a86c70904091013l2d7c2b77ic7f6988e6e7709f2@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Maksim Yevmenkin wrote: > On Thu, Apr 9, 2009 at 12:00 AM, Iain Hibbert <plunky@rya-online.net> wrote: > >> 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? > That's exactly the question I set about reading code in order to answer. The short version is, yes, in my opinion it's easier to just crib the existing APIs rather than rewrite the OS support code for all of these higher layer Bluetooth APIs completely from scratch. Dealing with JNI code can be a bit messy. I don't do Java on a daily basis so I'm less inclined to get my hands dirty with ant build.xml files. Other folks' mileage may vary. > > 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: > A bit of background: The whole reason we migrated to BSD in the first place was simply because it offered a faster route to building an appliance-like product than customizing Linux, unless we purchased an expensive license for a Linux derived embedded distribution. There are alternatives in the Linux space to this too, but even they have a high degree of change cost associated with them. We're talking about the difference between 1.5 man- days and 10 man-days. From a business point of view, that's a no brainer. If you look at the libhci drop I provided, you'll see I've tried to keep the BlueZ and NetBT compatibility shims separate from the core API. It is ifdef city. Iain: If you want to see this code give me a shout and I'll throw it up somewhere. I would hope to do the same for libsdp. > 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. > The thing is, if we go down this road, it would be wise to name the BSD libraries, structs and functions completely differently from their Linux counterparts, due to exactly the situation you describe so well below. As I say, I am happy to play along and adapt what I'm doing to the base system work that you guys want to do, however, the crucial part is that we are able to develop something without having to go directly to C/C++ every time. Doing this kind of work to the standard required, and on time, is difficult, and not all folk working as developers in this space have the requisite skills, nor the time to battle-test such code. Also, hardcore C/C++ comms software developers are not folk you can just pick up on a recruitment milk round. ;-) Accessibility is paramount. Projects like PyBlueZ already go far towards achieving this goal, which is why they are important. It's much easier to prototype, test, and design in Python, than it is in C. The development cycle is much shorter. > 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. > > Yes. BlueCove actually already has to do this for some SDP specifics -- it will do a dlopen() of libhci, look for a given function name, and it will use different SDP calls if a certain function isn't present. Some Linux-related projects have had something of a poor track record as regards change control and versioning of APIs. Yes, they do push further and faster, but we are then left with a legacy of kludge, much like GLIBC, which just gets in the way when trying to deliver product. I agree that it's reasonable to push a compatibility layer into ports. If you look at what Luigi Rizzo did with Linux USB webcam drivers, you'll see this too -- it saves code churn on the FreeBSD SVN repository. And separate change control for this kind of project is preferable for all sorts of reasons. >> 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. > Provided the ioctls are there :-) I have not needed to touch Netgraph specifics apart from this one thorny problem of getting a unique integer ID for each interface. Of course, persistence of the identifier between reboots / changes is a whole other matter -- and it affects e.g. Ethernet interfaces too. The way BlueZ has chosen to deal with this problem, in the 4.x/SVN train, is to keep bluetoothd state under /var/lib/bluetooth/ma:ca:dd:re:ss/*. But it still means that the dev_id has to be looked up at runtime, and thence the device opened. To be fair, this is no different e.g. from a standards-aware IP multicast application having to be aware of each individual link configured in the system, although a lot of grotty code in open-source land still isn't doing this (even though it's been in the RFCs for WAYYY over 5 years -- Come on guys, it's even in the textbooks... and the more TCP and Torrent saturated the 'Net gets, the more multicast matters!!) I would love to hear everyone's thoughts on how to deal with this issue. > >> 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). > > That seems reasonable. I should point out that a lot of the BlueZ consumer code I've looked at is using 'hci_get_route(NULL)' to get a dev_id for the first available dongle. It's actually a deceptively named API because it does not perform a 'route lookup' as such, it doesn't look at neighbour caches, LMP connection handles, etc. It just looks for the first dongle which doesn't correspond to the argument provided. ... re DBus: > 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. > That is exactly the barrier which Alexei and I ran head first into back in January, when we seriously started looking at this space. Again, the chaotic approach will let one push forward thick and fast, but it doesn't always yield the best long term result. As I say, I haven't had time to look at the DBus integration to figure out in which respects it differs, or is Linux/BlueZ specific. The BlueZ project team focus at the moment seems to be on DBus. What is clear is that the KDE bluetooth subsystem had to be completely rewritten for the new DBus semantics. ... > 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. > It is most likely a case of 'you get the Bluetooth LMP stack you pay for'. ;-) If you look at the list of Bluetooth SIG members, most of them aren't in a pure software play, but have invested in doing the baseband and microcontroller work from the ground up. CSR and Broadcom are manufacturing mass-market Bluetooth devices. I'm sure they supply specialized product line to the mobile phone industry, but in the main, Bluetooth chipsets intended for use with PCs are probably more limited in what they can do than what is actually possible with what's inside the plastic. This is another reason why Iain's suggestion that we appeal to such companies to contribute BSD code may fall down -- the chances are, if they are looking to dominate the space, they have probably already invested in proprietary OS solutions for building platforms. Although I certainly can't speak for Iain's relationship with Itronix, I am most interested and curious about their reasons for diving into the Bluetooth space, and why NetBSD of all platforms ;-) ...given who their main customer base is. Also, there has been a movement in terms of strategy by technology companies to adopt GPLv2 as an alternative, not because they believe it gives them some open source credibility, although that is part of the smokescreen sometimes -- more because the terms of the GPLv2 force potential competitors to give you their code, if they derive their work from yours. That isn't cut and dried fact, it's just based on observation of who is doing what and why. > 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 > ... > > 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). > Yup, please see my other recent reply to Iain where I noted down the bit in the specs about it being *suggests* that ACLs are held/parked/sniffed, however, the spec does not make this mandatory -- except for eSCO frames, which have reserved time slots at the Bluetooth baseband layer. At the moment, FreeBSD's stack doesn't do SCO, to my knowledge, nor do my colleague or I make use of SCO yet. it is something we'd want to play with in the not so distant future, though. cheers, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49DE4E2F.2000805>