libhci update

[Bruce Simpson]

Maksim Yevmenkin wrote:
> On Thu, Apr 9, 2009 at 12:00 AM, Iain Hibbert <plunky at 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