From owner-freebsd-bluetooth@FreeBSD.ORG Fri Apr 10 09:22:57 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A7131065672 for ; Fri, 10 Apr 2009 09:22:57 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp01.one2one.net (smtp01.one2one.net [149.254.200.196]) by mx1.freebsd.org (Postfix) with ESMTP id 885858FC16 for ; Fri, 10 Apr 2009 09:22:56 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1LsCwk-0007oF-Na; Fri, 10 Apr 2009 10:22:50 +0100 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30009-01; Fri, 10 Apr 2009 10:22:50 +0100 (BST) Received: from [10.216.29.42] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1LsCwc-0007o4-TE; Fri, 10 Apr 2009 10:22:50 +0100 Received: (nullmailer pid 907 invoked by uid 1000); Fri, 10 Apr 2009 09:21:26 -0000 Date: Fri, 10 Apr 2009 10:21:26 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <49DE4E2F.2000805@incunabulum.net> <49DE6D42.6000004@incunabulum.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1239355286.061485.927.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on smtpbarns01); SAEximRunCond expanded to false Cc: "freebsd-bluetooth@freebsd.org" , "alexei@raylab.com" , Bruce Simpson Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 09:22:57 -0000 On Thu, 9 Apr 2009, Maksim Yevmenkin wrote: > On Thu, Apr 9, 2009 at 1:48 PM, Bruce Simpson 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