Date: Thu, 9 Apr 2009 12:37:03 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: Bruce Simpson <bms@incunabulum.net> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org>, "alexei@raylab.com" <alexei@raylab.com> Subject: Re: libhci update Message-ID: <bb4a86c70904091337x7061ab5uf57bbaff1d5f3197@mail.gmail.com> In-Reply-To: <49DE4E2F.2000805@incunabulum.net> References: <49D92E26.2030508@incunabulum.net> <bb4a86c70904061358l3983ed51m11265859a833f202@mail.gmail.com> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <bb4a86c70904091013l2d7c2b77ic7f6988e6e7709f2@mail.gmail.com> <49DE4E2F.2000805@incunabulum.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 9, 2009 at 11:36 AM, Bruce Simpson <bms@incunabulum.net> wrote: > Maksim Yevmenkin wrote: [...] >> 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. yes, i looked at it. i saw what are you talking about. believe me, i know *exactly* what are you talking about here. that is why i suggested to put your existing code to ports/. this way you get to use it right now and avoid re-hacking things all the time. hell, if we were talking only about freebsd here, i would probably not object to put it into the base right now. however, i really, really want to keep compatibility and consistency here. at least with other bsd's. i'm still kicking myself for putting all those ng_ prefixes everywhere in userland code and not choosing location for headers wisely (it was long time ago and i was not a committer back then, so everything was developed outside of the main tree). i wish someone would point it to me back then. anyway, the last thing i want to do is to introduce even more differences. most likely (and correct me if i wrong here) Iain would never accept something like libhci into base. at least not in its current form. > I would hope to do the same for libsdp. well, here is where things might get a bit tricky because of sdpd(8). depending on what you want to do, you might need to bring both libsdp and sdpd (or whatever it is called these days) from bluez. >> 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. yes, unfortunately that is true, but that is where libhci compat port comes to the rescue. yes, it would not be pretty. yes, most functions will just copy data and silly stuff like that. but it least it will be separate and will be maintainable (or so i hope). > 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. i understand and can relate to what you are saying. again, we do not keep things like python, gmake, autoconf, etc. etc. in base. we do keep them in ports/. so, imo, it makes sense to keep libhci compat layer in ports/ too. you get to use bluez libhci and we get to keep our base tree clean. its a win-win to me :) >> 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. why even bother with that? just install compat library and have all the symbols available, no? > 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. great! i will try to clean up my patches and send them out one more time. i'd like to get Iain's comments before putting them into the base. mfc can be done quickly as well (if needed). >>> 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. let me know what is missing and i will add it :) > Of course, persistence of the identifier between reboots / changes is a > whole other > matter -- and it affects e.g. Ethernet interfaces too. that is the thing. bd_addr is the only "unique" (it can't be easily changed, but it still can be done) thing about bluetooth device. but in order to get it, you need to address the device somehow. devname is better, but still does not solve the problem as you pointed out it can change. > 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. why do you care so much about devid? i assume whatever it is you are building, it will have multiple radios, right? are you planning to setup different radios in different way? >>> 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. yep, the whole devid vs. devname difference only matters when you have more than 1 radio connected to the system. 99% of the people have only 1 radio, so it does not matter that much. [...] >> 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. i actually have a hands on experience with csr bluecore chips. i did some work with csr bluecore chips and csr bluelab sdk. i'm not sure if you know, but bluecore chips are actually bluetooth system-on-chip. that is you can run custom application on the chip itself. before bluecore5 the application was running inside the virtual machine running on bluecore. starting with bluecore5 you actually have a choice to run application natively or run it inside vm. firmware for bluecore chips comes in few flavors: low end goes up to hci layer only. that is what you will find in almost all consumer bluetooth dongles that use csr bluecore. in fact, almost all of them are based on bluecore-rom reference designs that are available from csr. high end goes up to rfcomm and hid layers. then you also have bluecoreX-mm (multimedia) chips that have dsp on board. those are typically used in mid/high end bluetooth headsets. the whole headset profile is actually running on bluecore chip. no external microcontroller is required. some dongles have dual personality - typical for hid dongles, i.e. you can have it to act as usb hub with keyboard and mouse (hid) or you can boot it into hci-only mode and it will look like regular bluetooth device. [...] > 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. there are some bits and pieces in various degree of working'ness :) thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70904091337x7061ab5uf57bbaff1d5f3197>