Date: Fri, 10 Apr 2009 10:21:26 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org>, "alexei@raylab.com" <alexei@raylab.com>, Bruce Simpson <bms@incunabulum.net> Subject: Re: libhci update Message-ID: <1239355286.061485.927.nullmailer@galant.ukfsn.org> In-Reply-To: <bb4a86c70904091537x1c6ec085r877d847268b38d3e@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> <49DE6D42.6000004@incunabulum.net> <bb4a86c70904091537x1c6ec085r877d847268b38d3e@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 9 Apr 2009, Maksim Yevmenkin wrote: > On Thu, Apr 9, 2009 at 1:48 PM, Bruce Simpson <bms@incunabulum.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 need. 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 > libbluetooth. 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? iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1239355286.061485.927.nullmailer>