Date: Thu, 09 Apr 2009 22:48:50 +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: <49DE6D42.6000004@incunabulum.net> In-Reply-To: <bb4a86c70904091337x7061ab5uf57bbaff1d5f3197@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> <49DE4E2F.2000805@incunabulum.net> <bb4a86c70904091337x7061ab5uf57bbaff1d5f3197@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Maksim Yevmenkin wrote:
> 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.
>
well said :-) It takes balls to admit our mistakes :-)
but we all make them, it's called "learning"... :-)
> 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.
>
Yup, base system addition isn't really my intent :-)
>
>> 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.
>
Yup, that's pretty scary because there are significant differences.
If you look at all the APIs, they all end up building
on-the-wire-records to advertise Bluetooth
services via SDP -- be that L2CAP PSM's, RFCOMM channels, or anything else.
it is irksome that the SDP APIs between OSes differ so radically.
So I'd make a radical suggestion here: can we change the existing
BSD-space applications
and daemons to use a different name e.g. libbtsdp for the base system?
That would be a big help for BlueZ compatibility... yes, it sucks, but
it's a hackish fix to the
namespace collision between these two radically different sets of libraries.
> 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 :)
>
Yup. Shipping in ports means we ship more quickly.
We've had to overcome some hurdles with 7.2-RELEASE, to be sure, but
most of what we
needed in the NOW, has been dealt with, and it's in FreeBSD 7.2 which
will be shipping
any minute now.
I loathe autotools with a passion, having had to hack with it
extensively for a living.
[re BlueCove dlopen() lameness]
> why even bother with that? just install compat library and have all
> the symbols available, no?
>
Now that you mention it, if libhci gets folded off into ports (hey,
let's call it comms/libhci),
it gets much easier...
>
>> 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).
>
>
>
OK. That would be great. I can look at such diffs too if need be. :-)
I don't believe an MFC will be too difficult as long as we're in the 7.2
slush.
We are tracking SVN stable/7 here, so even if it doesn't make it into
7.2-RELEASE,
all is not lost for what my partner and I are trying to do.
[ioctls]
> let me know what is missing and i will add it :)
>
What's the easiest way to get the unit number?
...
I think your non-Netgraph based solution is simpler and more elegant,
although it was nice to have
the exercise of getting my hands dirtier with Netgraph :-)
>
> 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.
>
It would be nice to have a 'device name' registry or be able to
renumber/rename the Bluetooth
dongles in a manner similar to that of what folk end up doing for
FreeBSD using ifconfig(8).
BTW: I should point out that FreeBSD doesn't actually do this for
network interfaces at the moment
in the base system in any automated way. The udev mechanisms in Linux
distributions do have
some provision for this. You can tell it to tie down instances to
specific PCI fields, usually vendor/chip.
It does bite ifnets in particular because FreeBSD's NEWBUS code
generally probes PCI buses
in the opposite order from Linux -- so dual-booted systems end up with a
different device tree,
as the unit numbers are assigned in inverse order.
The way people tend to work around this in practice is to construct
some sort of device registry
of their own, on top of what's already in base. I know previous clients
of mine have been doing
this, without naming names, and I know pfSense does something like this.
> 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?
>
Because... (bad English ;o))
yes we do want to use multiple radios -- inquiry is an expensive
operation -- and also,
BlueCove/JSR-82, PyBlueZ and the other high level language stuff
currently wants to use
dev_id as the unique endpoint identifier. :-(
They do provide APIs to lookup dev_id from the MAC address, but if that
is used as-is,
any port would still have to maintain the kludge. It is irritating, but
that is what has unfolded.
...
> 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.
>
Absolutely.
Only when you actually want to do something that is a bit more
complicated than uploading
your home-made pornography to your laptop, does having more than 1
Bluetooth radio
get important.
;-D
> [...]
>
>
>
> 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.
>
I saw this when using dfutool under Linux to flash a generic
BlueCore4-EXT dongle with the
generic CSR firmware. It turned out this image was extracted from a
MacBook integrated
Bluetooth dongle, so it presented itself as a USB HID device.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49DE6D42.6000004>