[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libhci update
- To: Maksim Yevmenkin <maksim_(_dot_)_yevmenkin_(_at_)_gmail_(_dot_)_com>
- Subject: Re: libhci update
- From: Iain Hibbert <plunky_(_at_)_rya-online_(_dot_)_net>
- Date: Fri, 10 Apr 2009 10:21:26 +0100 (BST)
- Cc: "freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org" <freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org>, "alexei_(_at_)_raylab_(_dot_)_com" <alexei_(_at_)_raylab_(_dot_)_com>, Bruce Simpson <bms_(_at_)_incunabulum_(_dot_)_net>
On Thu, 9 Apr 2009, Maksim Yevmenkin wrote:
> On Thu, Apr 9, 2009 at 1:48 PM, Bruce Simpson <bms_(_at_)_incunabulum_(_dot_)_net> wrote:
> > 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.
> oh, no :) please do not open this can of worms :) Iain knows its a
> very touchy subject with me :) i dislike *intensely* the fact that sdp
> records have to be built in on-the-wire format.
My view is that the on-the-wire format is not actually difficult to deal
with :) Certainly at the C level where the application programmer must
generally deal with data formats directly anyway. and the library handles
the common cases of talking to a remote device and fetching the data you
Yes, I think it is desireable to create a higher level object oriented
class based API (Python, C++, Java etc) but any such can build on top of
the data manipulation primitives I've made (and, I'm a C programmer so its
likely not me that will define it :) or use its own.
> yes, we can. i was actually thinking to merge add the sdp stuff into
definitely this and its not that difficult.
> and while i'm at it, move bluetooth.h and sdp.h into
> include/bluetooth/ where it belongs.
this is more problematic though and I don't think it is necessary. Because
include files are only needed at build time, the fact of filenames
conflicting with build environment can be worked around by adjusting the
build environment. (I think pkgsrc manages this, if ports does not then it
needs to :)
> so just enumerate all the radios (i.e. list all the hci nodes - there
> is an ioctl for that) and unit will be the number before "hci" part of
> the name. however, that will only work if if have devices of the same
> type in the system (i.e. all the radios are bluetooth dongles).
> otherwise, if, say, you have 3com pccard and bluetooth dongle, then
> you will have btccc0hci and ubt0hci nodes both having 0 unit number.
You could just use the enumeration number as device_id although that
causes problems if you remove a device as it will change.
Or, just assign an incrementing number for every device inserted. I don't
see why you would have to care that the device had previously been
inserted or try to produce the same number, as trying to manage a truly
dynamic hardware configuration is going to be a nightmare however you look
at it and I don't see why we should try to encourage it :)
(nor do I concede in any way that requiring the user to *ever* provide a
'device number' is a good idea)
> >> 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).
> i'm not quite follow why is that needed?
In fact FreeBSD does this already, you can just list the device bdaddr in
your hosts file and refer to it as 'white_dongle' or whatever you want. I
resisted this in NetBSD (somebody asked for it once but he didn't want to
have a public discussion about it so I remained unconvinced) and provided
bt_devaddr(3) as I think it could be better to have a generic method of
device mapping rather than a bunch of subsystem hacks.
> > and also, BlueCove/JSR-82, PyBlueZ and the other high level language
> > stuff currently wants to use dev_id as the unique endpoint identifier.
> > :-(
I don't understand this; BlueCove is a Java API and I don't see (looking
at the website) anything about device_id in the API? They provide
LocalDevice class which is obscure - it might use dev_id internally in the
BlueZ module but surely the Windows module does not?
freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe_(_at_)_freebsd_(_dot_)_org"
Visit your host, monkey.org