Date: Thu, 09 Apr 2009 01:27:14 +0100 From: Bruce Simpson <bms@incunabulum.net> To: Maksim Yevmenkin <emax@freebsd.org> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org>, "alexei@raylab.com" <alexei@raylab.com> Subject: Re: libhci update Message-ID: <49DD40E2.5030403@incunabulum.net> In-Reply-To: <bb4a86c70904061358l3983ed51m11265859a833f202@mail.gmail.com> References: <49D92E26.2030508@incunabulum.net> <bb4a86c70904061358l3983ed51m11265859a833f202@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Maksim Yevmenkin wrote: > > right, a few things. > > - dev_id is kinda gross, imo. Iain and i discussed this and agreed > that devname is the way to go. mapping between dev_id and devname can > be (has to be) done and i have no objection to this, however, all the > native api probably should use devname and not dev_id; > I agree with you here, but that doesn't change the fact that we are potentially being Betamax'd by BlueZ, even if not intentionally ;-) FYI if you are not familiar with the story of Betamax: it was the technological superior of the VHS video cassette standard, bot of course VHS got the dominant market share, and therefore won out in the end. > - all the hci_xxx functions (with possible exception of inquiry) > should probably be left out of the library. there is really not enough > consumers for them; > 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. This might not be the case for Bluetooth daemons in the base system, and much of what is in BlueZ, is used by its daemons. Given that I've read a lot of BlueZ code now, I can't entirely claim that my implementation of the API is truly clean-room. > - i not sure i like, hci_xxx names; Iain and i have been discussing > this before and agreed that, bt_XXX and bt_devXXXX are better names; > Well, the thing is, folk have already gone off and started building high-level language APIs on top of the BlueZ C language APIs. I understand from the 'code purity' point of view why one would be keen to adopt this kind of compartmentalization in terms of naming conventions. The problem is that the horse has already left the cart. 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. I realize this might be an inelegant approach, but it's based on observation of harsh commercial realities. > i'm attaching the diffs that was sitting in my queue (still need to > update man pages). please take a look at it and let me know what you > think. > Looks very similar in places to some of the code Markus wrote which I worked with. We certainly need an easy to use API which doesn't concern high level language users with too many of the specifics of low level I/O event handling. >> The API is now compatible with the current BlueZ SVN code. One of the >> trade-offs involved was choosing an identifier which would fit in an 'int' >> type, as BlueZ identifies its devices using uint16_t. >> >> As a compromise, I wrote code which emulates BlueZ device enumeration >> using the Netgraph node ID (32 bits wide). Unfortunately this introduces >> a dependency on -lnetgraph, unless the Bluetooth stack is itself taught to >> produce such an identifier (and supply it via an ioctl()). >> > > i actually went this route before :) but i opted for much simpler scheme: > <SNIP> > 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. > ... >> raise any other events *at all* at the HCI layer during inquiry. >> >> Mind you, I haven't tried any of the Bluetooth HCI 2.0/EDR commands, >> many of these are not yet implemented in the FreeBSD stack, am I right? >> > > well, most of 2.0 commands do not need any implementation. just need > to add defines and typedefs. some events might need handling, i.e. > inquiry with rssi. but generally it should just work. > I agree with you up to the point where 'it should just work'. A lot of what goes on with Bluetooth is actually going on behind closed doors. There are individuals (whom I won't name here to defend them from any possible litigation) who have found it necessary to disassemble what's actually going on with the 16-bit microcontrollers found in most Bluetooth devices. There have also been moves on the part of the Bluetooth SIG to make it harder to find information about Bluetooth's actual operation itself, as I am also sure you are aware. Nevertheless, that's largely orthogonal to the issues of implementing Bluetooth 2.0/EDR compatibility. What is clear is that the BlueZ API has moved with the times, and ours hasn't. My hope is that by actually using Bluetooth for interesting applications, that will help to drive interest forward. One observation I make from the current state of the BlueZ SVN code is that their primary focus is on desktop integration. If they were really serious, this work would already have been completed. As things stand, BlueZ as a platform is missing a few things which would make it easier to build Bluetooth server applications. ... Back to periodic inquiry: I am very surprised that given Bluetooth's value as a highly localized network, that the implementation of periodic inquiry, a feature pretty much essential to building endpoint discovery in a highly dynamic network environment, would tie up the whole microcontroller for the duration of the inquiry. 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. It's a bit of a cop out, to be sure, and we can certainly work around this by using a dedicated dongle to perform neighbor discovery. But why didn't they think about this in the spec? That begs the question. > >> I also had a crack at porting NetBSD's 'btconfig'. I haven't included it in >> this drop, however, it does depend on the libhci functions I have written. >> > > how about just fixing hcicontrol(8) do to that you want? is this too much work? > Whilst hccontrol(8) is an excellent and very complete tool, it is perhaps too complete for its own good. It captures a fairly complete set of the HCI commands normally used to manipulate Bluetooth host controller devices. However, it isn't terribly user friendly. My motivation in porting NetBSD's btconfig was more to do with the fact that it captures common use cases much like Linux BlueZ's hcitool -- i.e. folk familiar with UNIX in general become familiar with ifconfig(8), and btconfig has very similar semantics. Whilst in the FreeBSD case this isn't terribly important -- the devd.conf integration is thorough and works at boot-time just fine for building appliances -- it's not great for operational use i.e. debugging or manual config where it's needed. I would agree with the view that ifconfig(8) has become something of a kitchen sink, and whilst I wouldn't initially attempt to integrate Bluetooth functionality with that tool, I wouldn't rule it out, either. > >> I see that NetBSD's libsdp does support 128 bit UUIDs. Whilst this is >> highly desirable, it is also a prerequisite for any of the high level >> language >> wrappers (e.g. PyBlueZ, BlueCove) which make use of SDP. >> > > ok, i will take a look at the diffs to see what is different. > Yeah, talk about two arrows going in opposite directions :-) I found when hacking with BlueCove on Windows, I had to tell it *explicity* to use 16-bit UUIDs so that most phones could see the services it was advertising. The SDP story is a mess, to be sure, and could do with better APIs everywhere. What developers tend to do, in my experience, is to avoid dealing with platform specifics -- *unless they absolutely have to* -- and focus on delivering the solution with APIs that they can readily grasp. Sadly, the SDP APIs on all platforms are sorely missing this casual ease-of-use. >> Anyway, let me know what you think. I am eager to get the SDP issues >> knocked on the head ASAP. >> > > right, that would likely be complete replacement of libsdp and sdpd. > If that's what it amounts to, I'll get my hands dirty. It's just essential for what my partner and I are trying to do, that we have high-level language bindings for Bluetooth features essential to building a server application, working on FreeBSD. I am willing to help out in any way I can to drive this forward. thanks and regards, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49DD40E2.5030403>