From owner-freebsd-bluetooth@FreeBSD.ORG Mon Apr 6 20:58:44 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 C9B091065983 for ; Mon, 6 Apr 2009 20:58:44 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 698558FC0C for ; Mon, 6 Apr 2009 20:58:44 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1463417yxm.13 for ; Mon, 06 Apr 2009 13:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=B/oaLoLe8NJDrra6d47Ntv1Z4Z6MYg9gGwQUpgTm8Jc=; b=VH16pEbTvYvHA5xAjMIipfY1Bq1fQJUh7JMGzemWAcki1pgehj1I+WohRWmYDFISNb INCjMv+2bdYkgaTBORQDRxStBsS8yRH/z+XFRO215g/xvJdSHG3YcfeDuxrOO+tE0rCX 2ifAglTg+i1GsJybULo4zD70iDHD+uGhmgvL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=wTMSmoo4wB0e6/MKZ2Hq7uRVVaCIrD9ThNoMhAvO58nRi315VTC+z5wC85oF8xoO4N dEzPZwOdHnl65iLmVyse9flozY4pHJS7KGklxp8cP1Itj+0gg5iMuUumHTQJS7J2Umgw 4S2VSXf6Nzm4linU/e48EoNvh3CP46yMpYCcY= MIME-Version: 1.0 Sender: maksim.yevmenkin@gmail.com Received: by 10.90.50.12 with SMTP id x12mr3368723agx.79.1239051523901; Mon, 06 Apr 2009 13:58:43 -0700 (PDT) In-Reply-To: <49D92E26.2030508@incunabulum.net> References: <49D92E26.2030508@incunabulum.net> Date: Mon, 6 Apr 2009 12:58:43 -0800 X-Google-Sender-Auth: 95fdc776297f3ef5 Message-ID: From: Maksim Yevmenkin To: Bruce Simpson Content-Type: multipart/mixed; boundary=00163630f4a9f0c9e20466e929c3 Cc: "freebsd-bluetooth@freebsd.org" , "alexei@raylab.com" 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: Mon, 06 Apr 2009 20:58:45 -0000 --00163630f4a9f0c9e20466e929c3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Bruce, > So I decided to just go ahead and reimplement Markus Brueffer's libhci. > I've attached a tarball of the Hg repository. thanks! > It would be great to have feedback from you about this. right, a few things. - dev_id is kinda gross, imo. Iain and i discussed this and agreed that devname is the way to go. mapping between dev_id and devname can be (has to be) done and i have no objection to this, however, all the native api probably should use devname and not dev_id; - all the hci_xxx functions (with possible exception of inquiry) should probably be left out of the library. there is really not enough consumers for them; - i not sure i like, hci_xxx names; Iain and i have been discussing this before and agreed that, bt_XXX and bt_devXXXX are better names; i'm attaching the diffs that was sitting in my queue (still need to update man pages). please take a look at it and let me know what you think. > The API is now compatible with the current BlueZ SVN code. One of the > trade-offs involved was choosing an identifier which would fit in an 'int' > type, as BlueZ identifies its devices using uint16_t. > > As a compromise, I wrote code which emulates BlueZ device enumeration > using the Netgraph node ID (32 bits wide). Unfortunately this introduces > a dependency on -lnetgraph, unless the Bluetooth stack is itself taught to > produce such an identifier (and supply it via an ioctl()). i actually went this route before :) but i opted for much simpler scheme: #define hci_devid2type(id) (((id) >> 12) & 0x0f) #define hci_devid2unit(id) ((id) & 0x0fff) #define hci_mkdevid(type, unit) ((((type) & 0x0f) << 12) | (unit & 0x0fff)) struct hci_type2prefix { int type; char const *prefix; }; static struct hci_type2prefix const type2prefix[] = { { .type = HCI_VIRTUAL, .prefix = NULL, }, { .type = HCI_USB, .prefix = "ubt", }, { .type = HCI_PCCARD, .prefix = "btccc", }, { .type = HCI_UART, .prefix = "h4", }, { .type = HCI_RS232, .prefix = NULL, }, { .type = HCI_PCI, .prefix = NULL, }, { .type = HCI_SDIO, .prefix = NULL, }, { .type = -1, .prefix = NULL, }, /* should be last */ }; static int hci_name2devid(char const *name) { struct hci_type2prefix const *t; int plen, unit; char *ep; for (t = &type2prefix[0]; t->type != -1; t ++) { if (t->prefix == NULL) continue; plen = strlen(t->prefix); if (strncmp(name, t->prefix, plen) != 0) continue; unit = strtoul(name + plen, &ep, 10); if (*ep != '\0' && strcmp(ep, "hci") != 0 && strcmp(ep, "l2cap") != 0) { errno = ENODEV; return (-1); } return (hci_mkdevid(t->type, unit)); } errno = ENODEV; return (-1); } static char * hci_devid2name(int dev_id, char *name, int namelen) { struct hci_type2prefix const *t; int type, unit; if (dev_id >= 0) { type = hci_devid2type(dev_id); unit = hci_devid2unit(dev_id); for (t = &type2prefix[0]; t->type != -1; t ++) { if (t->type == type && t->prefix != NULL) { snprintf(name, namelen, "%s%uhci", t->prefix, unit); return (name); } } } errno = EINVAL; return (NULL); } this code is left out for now. not sure if i like it :) > I noticed during the port that periodic inquiry doesn't actually buy us > anything > at all. With a CSR BlueCore4-ROM dongle, the microcontroller will not > raise any other events *at all* at the HCI layer during inquiry. > > Mind you, I haven't tried any of the Bluetooth HCI 2.0/EDR commands, > many of these are not yet implemented in the FreeBSD stack, am I right? well, most of 2.0 commands do not need any implementation. just need to add defines and typedefs. some events might need handling, i.e. inquiry with rssi. but generally it should just work. > I also had a crack at porting NetBSD's 'btconfig'. I haven't included it in > this drop, however, it does depend on the libhci functions I have written. how about just fixing hcicontrol(8) do to that you want? is this too much work? > I see that NetBSD's libsdp does support 128 bit UUIDs. Whilst this is > highly desirable, it is also a prerequisite for any of the high level > language > wrappers (e.g. PyBlueZ, BlueCove) which make use of SDP. ok, i will take a look at the diffs to see what is different. > Anyway, let me know what you think. I am eager to get the SDP issues > knocked on the head ASAP. right, that would likely be complete replacement of libsdp and sdpd. thanks, max --00163630f4a9f0c9e20466e929c3 Content-Type: text/plain; charset=US-ASCII; name="bluetooth.hci.diff.txt" Content-Disposition: attachment; filename="bluetooth.hci.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ft7myoeu1 SW5kZXg6IGhjaS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGhjaS5jCShyZXZpc2lvbiAxOTA1OTQpCisrKyBo Y2kuYwkod29ya2luZyBjb3B5KQpAQCAtMzAsMTUgKzMwLDQyMSBAQAogICogJEZyZWVCU0QkCiAg Ki8KIAorI2luY2x1ZGUgPGFzc2VydC5oPgogI2luY2x1ZGUgPGJsdWV0b290aC5oPgogI2luY2x1 ZGUgPHN0ZGlvLmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CiAj aW5jbHVkZSA8dW5pc3RkLmg+CiAKK3N0YXRpYyBpbnQgICAgYnRfZGV2YW55X2NiKGludCBzLCBz dHJ1Y3QgYnRfZGV2aW5mbyBjb25zdCAqZGksIHZvaWQgKnhkZXZuYW1lKTsKIHN0YXRpYyBjaGFy ICogYnRfZGV2Mm5vZGUgKGNoYXIgY29uc3QgKmRldm5hbWUsIGNoYXIgKm5vZGVuYW1lLCBpbnQg bm5sZW4pOwogCiBpbnQKK2J0X2Rldm9wZW4oY2hhciBjb25zdCAqZGV2bmFtZSkKK3sKKwlzdHJ1 Y3Qgc29ja2FkZHJfaGNpCWhhOworCWJkYWRkcl90CQliYTsKKwlpbnQJCQlzOworCisJaWYgKGRl dm5hbWUgPT0gTlVMTCkgeworCQllcnJubyA9IEVJTlZBTDsKKwkJcmV0dXJuICgtMSk7CisJfQor CisJbWVtc2V0KCZoYSwgMCwgc2l6ZW9mKGhhKSk7CisJaGEuaGNpX2xlbiA9IHNpemVvZihoYSk7 CisJaGEuaGNpX2ZhbWlseSA9IEFGX0JMVUVUT09USDsKKworCWlmIChidF9hdG9uKGRldm5hbWUs ICZiYSkpIHsKKwkJaWYgKCFidF9kZXZuYW1lKGhhLmhjaV9ub2RlLCAmYmEpKQorCQkJcmV0dXJu ICgtMSk7CisJfSBlbHNlIGlmIChidF9kZXYybm9kZShkZXZuYW1lLCBoYS5oY2lfbm9kZSwKKwkJ CQkJc2l6ZW9mKGhhLmhjaV9ub2RlKSkgPT0gTlVMTCkgeworCQllcnJubyA9IEVOWElPOworCQly ZXR1cm4gKC0xKTsKKwl9CisKKwlzID0gc29ja2V0KFBGX0JMVUVUT09USCwgU09DS19SQVcsIEJM VUVUT09USF9QUk9UT19IQ0kpOworCWlmIChzIDwgMCkKKwkJcmV0dXJuICgtMSk7CisKKwlpZiAo YmluZChzLCAoc3RydWN0IHNvY2thZGRyICopICZoYSwgc2l6ZW9mKGhhKSkgPCAwIHx8CisJICAg IGNvbm5lY3QocywgKHN0cnVjdCBzb2NrYWRkciAqKSAmaGEsIHNpemVvZihoYSkpIDwgMCkgewor CQljbG9zZShzKTsKKwkJcmV0dXJuICgtMSk7CisJfQorCisJcmV0dXJuIChzKTsKK30KKworaW50 CitidF9kZXZjbG9zZShpbnQgcykKK3sKKwlyZXR1cm4gKGNsb3NlKHMpKTsKK30KKworaW50Citi dF9kZXZzZW5kKGludCBzLCB1aW50MTZfdCBvZ2YsIHVpbnQxNl90IG9jZiwgaW50IHBsZW4sIHZv aWQgKnBhcmFtKQoreworCW5nX2hjaV9jbWRfcGt0X3QJaDsKKwlzdHJ1Y3QgaW92ZWMJCWl2WzJd OworCWludAkJCWl2bjsKKworCWlmIChwbGVuIDwgMCB8fCAocGxlbiA+IDAgJiYgcGFyYW0gPT0g TlVMTCkpIHsgCisJCWVycm5vID0gRUlOVkFMOworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwlpdlsw XS5pb3ZfYmFzZSA9ICZoOworCWl2WzBdLmlvdl9sZW4gPSBzaXplb2YoaCk7CisJaXZuID0gMTsK KworCWgudHlwZSA9IE5HX0hDSV9DTURfUEtUOworCWgub3Bjb2RlID0gaHRvbGUxNihOR19IQ0lf T1BDT0RFKG9nZiwgb2NmKSk7CisJaWYgKHBsZW4gPiAwKSB7CisJCWgubGVuZ3RoID0gcGxlbjsK KworCQlpdlsxXS5pb3ZfYmFzZSA9IHBhcmFtOworCQlpdlsxXS5pb3ZfbGVuID0gcGxlbjsKKwkJ aXZuID0gMjsKKwl9IGVsc2UKKwkJaC5sZW5ndGggPSAwOworCisJd2hpbGUgKHdyaXRldihzLCBp diwgaXZuKSA8IDApIHsKKwkJaWYgKGVycm5vID09IEVBR0FJTiB8fCBlcnJubyA9PSBFSU5UUikK KwkJCWNvbnRpbnVlOworCisJCXJldHVybiAoLTEpOworCX0KKworCXJldHVybiAoMCk7Cit9CisK K2ludAorYnRfZGV2cmVjdihpbnQgcywgdWludDhfdCAqYnVmLCBpbnQgc2l6ZSwgdGltZV90IHRv KQoreworCWZkX3NldAkJcmZkOworCXN0cnVjdCB0aW1ldmFsCXR2OworCWludAkJbjsKKworCWlm IChidWYgPT0gTlVMTCB8fCBzaXplIDw9IDAgfHwgdG8gPCAwKSB7CisJCWVycm5vID0gRUlOVkFM OworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwlGRF9aRVJPKCZyZmQpOworCUZEX1NFVChzLCAmcmZk KTsKKworCXR2LnR2X3NlYyA9IHRvOworCXR2LnR2X3VzZWMgPSAwOworCisJd2hpbGUgKChuID0g c2VsZWN0KHMgKyAxLCAmcmZkLCBOVUxMLCBOVUxMLCAmdHYpKSA8IDApIHsKKwkJaWYgKGVycm5v ID09IEVBR0FJTiB8fCBlcnJubyA9PSBFSU5UUikKKwkJCWNvbnRpbnVlOworCisJCXJldHVybiAo LTEpOworCX0KKworCWlmIChuID09IDApIHsKKwkJZXJybm8gPSBFVElNRURPVVQ7CisJCXJldHVy biAoLTEpOworCX0KKworCWFzc2VydChGRF9JU1NFVChzLCAmcmZkKSk7CisKKwl3aGlsZSAoKG4g PSByZWFkKHMsIGJ1Ziwgc2l6ZSkpIDwgMCkgeworCQlpZiAoZXJybm8gPT0gRUFHQUlOIHx8IGVy cm5vID09IEVJTlRSKQorCQkJY29udGludWU7CisKKwkJcmV0dXJuICgtMSk7CisJfQorCisJcmV0 dXJuIChuKTsKK30KKworaW50CitidF9kZXZyZXEoaW50IHMsIHN0cnVjdCBidF9kZXZyZXEgKnIs IHRpbWVfdCB0bykKK3sKKwl1aW50OF90CQkJCWJ1ZlszMjBdOyAvKiBtb3JlIHRoYW4gZW5vdWdo ICovCisJbmdfaGNpX2V2ZW50X3BrdF90CQkqZSA9IChuZ19oY2lfZXZlbnRfcGt0X3QgKikgYnVm OworCW5nX2hjaV9jb21tYW5kX2NvbXBsX2VwCQkqY2MgPSAobmdfaGNpX2NvbW1hbmRfY29tcGxf ZXAgKikoZSsxKTsKKwluZ19oY2lfY29tbWFuZF9zdGF0dXNfZXAJKmNzID0gKG5nX2hjaV9jb21t YW5kX3N0YXR1c19lcCopKGUrMSk7CisJdWludDE2X3QJCQlvcGNvZGU7CisJdGltZV90CQkJCXRf ZW5kOworCWludAkJCQluOworCisJaWYgKHMgPCAwIHx8IHIgPT0gTlVMTCB8fCB0byA8IDApIHsK KwkJZXJybm8gPSBFSU5WQUw7CisJCXJldHVybiAoLTEpOworCX0KKworCWlmIChyLT5ybGVuIDwg MCB8fCAoci0+cmxlbiA+IDAgJiYgci0+cnBhcmFtID09IE5VTEwpKSB7CisJCWVycm5vID0gRUlO VkFMOworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwluID0gYnRfZGV2c2VuZChzLCByLT5vZ2YsIHIt Pm9jZiwgci0+Y2xlbiwgci0+Y3BhcmFtKTsKKwlpZiAobiA8IDApCisJCXJldHVybiAoLTEpOwor CisJb3Bjb2RlID0gaHRvbGUxNihOR19IQ0lfT1BDT0RFKHItPm9nZiwgci0+b2NmKSk7CisKKwl0 X2VuZCA9IHRpbWUoTlVMTCkgKyB0bzsKKworCWRvIHsKKwkJdG8gPSB0X2VuZCAtIHRpbWUoTlVM TCk7CisJCWlmICh0byA8IDApCisJCQl0byA9IDA7CisKKwkJbiA9IGJ0X2RldnJlY3YocywgYnVm LCBzaXplb2YoYnVmKSwgdG8pOworCQlpZiAobiA8IDApCisJCQlyZXR1cm4gKC0xKTsKKworCQlp ZiAobiA8IHNpemVvZigqZSkpIHsKKwkJCWVycm5vID0gRU1TR1NJWkU7CisJCQlyZXR1cm4gKC0x KTsKKwkJfQorCisJCWlmIChlLT50eXBlICE9IE5HX0hDSV9FVkVOVF9QS1QpIHsKKwkJCWVycm5v ID0gRUlPOworCQkJcmV0dXJuICgtMSk7CisJCX0KKworCQluIC09IHNpemVvZigqZSk7CisKKwkJ c3dpdGNoIChlLT5ldmVudCkgeworCQljYXNlIE5HX0hDSV9FVkVOVF9DT01NQU5EX0NPTVBMOgor CQkJaWYgKGNjLT5vcGNvZGUgPT0gb3Bjb2RlKSB7CisJCQkJbiAtPSBzaXplb2YoKmNjKTsKKwor CQkJCWlmIChyLT5ybGVuID49IG4pIHsKKwkJCQkJci0+cmxlbiA9IG47CisJCQkJCW1lbWNweShy LT5ycGFyYW0sIGNjICsgMSwgci0+cmxlbik7CisJCQkJfQorCisJCQkJcmV0dXJuICgwKTsKKwkJ CX0KKwkJCWJyZWFrOworCisJCWNhc2UgTkdfSENJX0VWRU5UX0NPTU1BTkRfU1RBVFVTOgorCQkJ aWYgKGNzLT5vcGNvZGUgPT0gb3Bjb2RlKSB7CisJCQkJaWYgKHItPmV2ZW50ICE9IE5HX0hDSV9F VkVOVF9DT01NQU5EX1NUQVRVUykgeworCQkJCQlpZiAoY3MtPnN0YXR1cyAhPSAwKSB7CisJCQkJ CQllcnJubyA9IEVJTzsKKwkJCQkJCXJldHVybiAoLTEpOworCQkJCQl9CisJCQkJfSBlbHNlIHsK KwkJCQkJaWYgKHItPnJsZW4gPj0gbikgeworCQkJCQkJci0+cmxlbiA9IG47CisJCQkJCQltZW1j cHkoci0+cnBhcmFtLCBjcywgci0+cmxlbik7CisJCQkJCX0KKworCQkJCQlyZXR1cm4gKDApOwor CQkJCX0KKwkJCX0KKwkJCWJyZWFrOworCisJCWRlZmF1bHQ6CisJCQlpZiAoZS0+ZXZlbnQgPT0g ci0+ZXZlbnQpIHsKKwkJCQlpZiAoci0+cmxlbiA+PSBuKSB7CisJCQkJCXItPnJsZW4gPSBuOwor CQkJCQltZW1jcHkoci0+cnBhcmFtLCBlICsgMSwgci0+cmxlbik7CisJCQkJfQorCisJCQkJcmV0 dXJuICgwKTsKKwkJCX0KKwkJCWJyZWFrOworCQl9CisJfSB3aGlsZSAodG8gPiAwKTsKKworCWVy cm5vID0gRVRJTUVET1VUOworCisJcmV0dXJuICgtMSk7Cit9CisKK2ludAorYnRfZGV2ZmlsdGVy KGludCBzLCBzdHJ1Y3QgYnRfZGV2ZmlsdGVyIGNvbnN0ICpuZXcsIHN0cnVjdCBidF9kZXZmaWx0 ZXIgKm9sZCkKK3sKKwlzdHJ1Y3QgbmdfYnRzb2NrZXRfaGNpX3Jhd19maWx0ZXIJZjsKKwlzb2Nr bGVuX3QJCQkJbGVuOworCWludAkJCQkJYml0OworCisJaWYgKG5ldyA9PSBOVUxMICYmIG9sZCA9 PSBOVUxMKSB7CisJCWVycm5vID0gRUlOVkFMOworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwlpZiAo b2xkICE9IE5VTEwpIHsKKwkJbGVuID0gc2l6ZW9mKGYpOworCQlpZiAoZ2V0c29ja29wdChzLCBT T0xfSENJX1JBVywgU09fSENJX1JBV19GSUxURVIsICZmLCAmbGVuKSA8IDApCisJCQlyZXR1cm4g KC0xKTsKKworCQltZW1zZXQob2xkLCAwLCBzaXplb2YoKm9sZCkpOworCisJCWZvciAoYml0ID0g MDsgYml0IDwgTkdfSENJX0VWRU5UX1BLVDsgYml0ICsrKQorCQkJaWYgKGJpdF90ZXN0KGYucGFj a2V0X21hc2ssIGJpdCkpCisJCQkJb2xkLT5wYWNrZXRfbWFzayB8PSAoMSA8PCBiaXQpOworCisJ CWZvciAoYml0ID0gMDsgYml0IDwgTkdfSENJX0VWRU5UX01BU0tfU0laRSAqIDg7IGJpdCArKykK KwkJCWlmIChiaXRfdGVzdChmLmV2ZW50X21hc2ssIGJpdCkpCisJCQkJb2xkLT5ldmVudF9tYXNr IHw9ICgxIDw8IGJpdCk7CisJfQorCisJaWYgKG5ldyAhPSBOVUxMKSB7CisJCW1lbXNldCgmZiwg MCwgc2l6ZW9mKGYpKTsKKworCQlmb3IgKGJpdCA9IDA7IGJpdCA8IE5HX0hDSV9FVkVOVF9QS1Q7 IGJpdCArKykKKwkJCWlmIChuZXctPnBhY2tldF9tYXNrICYgKDEgPDwgYml0KSkKKwkJCQliaXRf c2V0KGYucGFja2V0X21hc2ssIGJpdCk7CisKKwkJZm9yIChiaXQgPSAwOyBiaXQgPCAoTkdfSENJ X0VWRU5UX01BU0tfU0laRSAqIDgpOyBiaXQgKyspCisJCQlpZiAobmV3LT5ldmVudF9tYXNrICYg KDEgPDwgYml0KSkKKwkJCQliaXRfc2V0KGYuZXZlbnRfbWFzaywgYml0KTsKKworCQlsZW4gPSBz aXplb2YoZik7CisJCWlmIChzZXRzb2Nrb3B0KHMsIFNPTF9IQ0lfUkFXLCBTT19IQ0lfUkFXX0ZJ TFRFUiwgJmYsIGxlbikgPCAwKQorCQkJcmV0dXJuICgtMSk7CisJfQorCisJcmV0dXJuICgwKTsK K30KKworaW50CitidF9kZXZpbnF1aXJ5KGNoYXIgY29uc3QgKmRldm5hbWUsIGludCBsZW5ndGgs IGludCBudW1fcnNwLAorCQl1aW50OF90IGNvbnN0ICpsYXAsIHN0cnVjdCBidF9kZXZpbnF1aXJ5 ICoqaWkpCit7CisJdWludDhfdAkJCQlidWZbMzIwXTsKKwljaGFyCQkJCV9kZXZuYW1lW0hDSV9E RVZOQU1FX1NJWkVdOworCXN0cnVjdCBidF9kZXZmaWx0ZXIJCWY7CisJbmdfaGNpX2lucXVpcnlf Y3AJCSpjcCA9IChuZ19oY2lfaW5xdWlyeV9jcCAqKSBidWY7CisJbmdfaGNpX2V2ZW50X3BrdF90 CQkqZSA9IChuZ19oY2lfZXZlbnRfcGt0X3QgKikgYnVmOworCW5nX2hjaV9pbnF1aXJ5X3Jlc3Vs dF9lcAkqZXAgPSAobmdfaGNpX2lucXVpcnlfcmVzdWx0X2VwICopKGUrMSk7CisJbmdfaGNpX2lu cXVpcnlfcmVzcG9uc2UJCSppcjsKKwlzdHJ1Y3QgYnRfZGV2aW5xdWlyeQkJKmk7CisJaW50CQkJ CXMsIG47CisJdGltZV90CQkJCXRvOworCisJaWYgKGlpID09IE5VTEwpIHsKKwkJZXJybm8gPSBF SU5WQUw7CisJCXJldHVybiAoLTEpOworCX0KKworCWlmIChkZXZuYW1lID09IE5VTEwpIHsKKwkJ bWVtc2V0KF9kZXZuYW1lLCAwLCBzaXplb2YoX2Rldm5hbWUpKTsKKwkJZGV2bmFtZSA9IF9kZXZu YW1lOworCisJCW4gPSBidF9kZXZlbnVtKGJ0X2RldmFueV9jYiwgX2Rldm5hbWUpOworCQlpZiAo biA8PSAwKSB7CisJCQlpZiAobiA9PSAwKQorCQkJCSppaSA9IE5VTEw7CisKKwkJCXJldHVybiAo bik7CisJCX0KKwl9CisKKwlzID0gYnRfZGV2b3BlbihkZXZuYW1lKTsKKwlpZiAocyA8IDApCisJ CXJldHVybiAoLTEpOworCisJaWYgKGJ0X2RldmZpbHRlcihzLCBOVUxMLCAmZikgPCAwKSB7CisJ CWJ0X2RldmNsb3NlKHMpOworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwlmLmV2ZW50X21hc2sgfD0g KDEgPDwgKE5HX0hDSV9FVkVOVF9JTlFVSVJZX0NPTVBMIC0gMSkpOworCWYuZXZlbnRfbWFzayB8 PSAoMSA8PCAoTkdfSENJX0VWRU5UX0lOUVVJUllfUkVTVUxUIC0gMSkpOworCisJaWYgKGJ0X2Rl dmZpbHRlcihzLCAmZiwgTlVMTCkgPCAwKSB7CisJCWJ0X2RldmNsb3NlKHMpOworCQlyZXR1cm4g KC0xKTsKKwl9CisKKwlpZiAobGFwID09IE5VTEwpIHsKKwkJY3AtPmxhcFswXSA9IDB4MzM7CisJ CWNwLT5sYXBbMV0gPSAweDhiOworCQljcC0+bGFwWzJdID0gMHg5ZTsKKwl9IGVsc2UgeworCQlj cC0+bGFwWzBdID0gbGFwWzBdOworCQljcC0+bGFwWzFdID0gbGFwWzFdOworCQljcC0+bGFwWzJd ID0gbGFwWzJdOworCX0KKworCWlmIChsZW5ndGggPD0gMCB8fCBsZW5ndGggPiAyNTUpCisJCWxl bmd0aCA9IDQ7CS8qIDUuMTIgc2Vjb25kcyAqLworCWNwLT5pbnF1aXJ5X2xlbmd0aCA9ICh1aW50 OF90KSBsZW5ndGg7CisKKwl0byA9ICh0aW1lX3QpKChkb3VibGUpIGxlbmd0aCAqIDEuMjgpICsg MTsKKworCWlmIChudW1fcnNwIDw9IDAgfHwgbnVtX3JzcCA+IDI1NSkKKwkJbnVtX3JzcCA9IDg7 CisJY3AtPm51bV9yZXNwb25zZXMgPSAodWludDhfdCkgbnVtX3JzcDsKKworCWkgPSAqaWkgPSBj YWxsb2MobnVtX3JzcCwgc2l6ZW9mKHN0cnVjdCBidF9kZXZpbnF1aXJ5KSk7CisJaWYgKGkgPT0g TlVMTCkgeworCQlidF9kZXZjbG9zZShzKTsKKwkJZXJybm8gPSBFTk9NRU07CisJCXJldHVybiAo LTEpOworCX0KKworCWlmIChidF9kZXZzZW5kKHMsIE5HX0hDSV9PR0ZfTElOS19DT05UUk9MLCBO R19IQ0lfT0NGX0lOUVVJUlksCisJCQlzaXplb2YoKmNwKSwgY3ApIDwgMCkgeworCQlmcmVlKGkp OworCQlidF9kZXZjbG9zZShzKTsKKwkJcmV0dXJuICgtMSk7CisJfQorCit3YWl0X2Zvcl9tb3Jl OgorCisJbiA9IGJ0X2RldnJlY3YocywgYnVmLCBzaXplb2YoYnVmKSwgdG8pOworCWlmIChuIDwg MCkgeworCQlmcmVlKGkpOworCQlidF9kZXZjbG9zZShzKTsKKwkJcmV0dXJuICgtMSk7CisJfQor CisJaWYgKG4gPCBzaXplb2YobmdfaGNpX2V2ZW50X3BrdF90KSkgeworCQlmcmVlKGkpOworCQli dF9kZXZjbG9zZShzKTsKKwkJZXJybm8gPSBFSU87CisJCXJldHVybiAoLTEpOworCX0KKworCXN3 aXRjaCAoZS0+ZXZlbnQpIHsKKwljYXNlIE5HX0hDSV9FVkVOVF9JTlFVSVJZX0NPTVBMOgorCQli cmVhazsKKworCWNhc2UgTkdfSENJX0VWRU5UX0lOUVVJUllfUkVTVUxUOgorCQlpciA9IChuZ19o Y2lfaW5xdWlyeV9yZXNwb25zZSAqKShlcCArIDEpOworCisjdW5kZWYJTUlOCisjZGVmaW5lCU1J TihhLCBiKQkoKChhKSA8IChiKSk/IChhKSA6IChiKSkKKworCQlmb3IgKG4gPSAwOyBuIDwgTUlO KGVwLT5udW1fcmVzcG9uc2VzLCBudW1fcnNwKTsgbiArKykgeworCQkJYmRhZGRyX2NvcHkoJmkt PmJkYWRkciwgJmlyLT5iZGFkZHIpOworCQkJaS0+cHNjYW5fcmVwX21vZGUgPSBpci0+cGFnZV9z Y2FuX3JlcF9tb2RlOworCQkJaS0+cHNjYW5fcGVyaW9kX21vZGUgPSBpci0+cGFnZV9zY2FuX3Bl cmlvZF9tb2RlOworCQkJaS0+cHNjYW5fbW9kZSA9IGlyLT5wYWdlX3NjYW5fbW9kZTsKKwkJCW1l bWNweShpLT5kZXZfY2xhc3MsIGlyLT51Y2xhc3MsIHNpemVvZihpLT5kZXZfY2xhc3MpKTsKKwkJ CWktPmNsb2NrX29mZnNldCA9IGxlMTZ0b2goaXItPmNsb2NrX29mZnNldCk7CisKKwkJCWlyICsr OworCQkJaSArKzsKKwkJCW51bV9yc3AgLS07CisJCX0KKwkJLyogRkFMTFRIUk9VR0ggKi8KKwor CWRlZmF1bHQ6CisJCWdvdG8gd2FpdF9mb3JfbW9yZTsKKwkJLyogTk9UIFJFQUNIRUQgKi8KKwl9 CisKKwlidF9kZXZjbG9zZShzKTsKKwkJCisJcmV0dXJuIChpIC0gKmlpKTsKK30KKworaW50CiBi dF9kZXZpbmZvKHN0cnVjdCBidF9kZXZpbmZvICpkaSkKIHsKIAl1bmlvbiB7CkBAIC01Myw2ICs0 NTksNyBAQAogCQlzdHJ1Y3QgbmdfYnRzb2NrZXRfaGNpX3Jhd19ub2RlX2RlYnVnCQlyODsKIAl9 CQkJCQkJcnA7CiAJc3RydWN0IHNvY2thZGRyX2hjaQkJCQloYTsKKwlzb2NrbGVuX3QJCQkJCWhh bGVuOwogCWludAkJCQkJCXMsIHJ2YWw7CiAKIAlpZiAoZGkgPT0gTlVMTCkgewpAQCAtNjAsMjcg KzQ2NywxNCBAQAogCQlyZXR1cm4gKC0xKTsKIAl9CiAKLQltZW1zZXQoJmhhLCAwLCBzaXplb2Yo aGEpKTsKLQloYS5oY2lfbGVuID0gc2l6ZW9mKGhhKTsKLQloYS5oY2lfZmFtaWx5ID0gQUZfQkxV RVRPT1RIOwotCi0JaWYgKGJ0X2F0b24oZGktPmRldm5hbWUsICZycC5yMS5iZGFkZHIpKSB7Ci0J CWlmICghYnRfZGV2bmFtZShoYS5oY2lfbm9kZSwgJnJwLnIxLmJkYWRkcikpCi0JCQlyZXR1cm4g KC0xKTsKLQl9IGVsc2UgaWYgKGJ0X2RldjJub2RlKGRpLT5kZXZuYW1lLCBoYS5oY2lfbm9kZSwK LQkJCQkJc2l6ZW9mKGhhLmhjaV9ub2RlKSkgPT0gTlVMTCkgewotCQllcnJubyA9IEVOWElPOwot CQlyZXR1cm4gKC0xKTsKLQl9Ci0KLQlzID0gc29ja2V0KFBGX0JMVUVUT09USCwgU09DS19SQVcs IEJMVUVUT09USF9QUk9UT19IQ0kpOworCXMgPSBidF9kZXZvcGVuKGRpLT5kZXZuYW1lKTsKIAlp ZiAocyA8IDApCiAJCXJldHVybiAoLTEpOwogCiAJcnZhbCA9IC0xOwogCi0JaWYgKGJpbmQocywg KHN0cnVjdCBzb2NrYWRkciAqKSAmaGEsIHNpemVvZihoYSkpIDwgMCB8fAotCSAgICBjb25uZWN0 KHMsIChzdHJ1Y3Qgc29ja2FkZHIgKikgJmhhLCBzaXplb2YoaGEpKSA8IDApCisJaGFsZW4gPSBz aXplb2YoaGEpOworCWlmIChnZXRzb2NrbmFtZShzLCAoc3RydWN0IHNvY2thZGRyICopICZoYSwg JmhhbGVuKSA8IDApCiAJCWdvdG8gYmFkOwogCXN0cmxjcHkoZGktPmRldm5hbWUsIGhhLmhjaV9u b2RlLCBzaXplb2YoZGktPmRldm5hbWUpKTsKIApAQCAtMTM4LDcgKzUzMiw3IEBACiAKIAlydmFs ID0gMDsKIGJhZDoKLQljbG9zZShzKTsKKwlidF9kZXZjbG9zZShzKTsKIAogCXJldHVybiAocnZh bCk7CiB9CkBAIC0yMDUsNiArNTk5LDEzIEBACiAJcmV0dXJuIChjb3VudCk7CiB9CiAKK3N0YXRp YyBpbnQKK2J0X2RldmFueV9jYihpbnQgcywgc3RydWN0IGJ0X2RldmluZm8gY29uc3QgKmRpLCB2 b2lkICp4ZGV2bmFtZSkKK3sKKwlzdHJsY3B5KChjaGFyICopIHhkZXZuYW1lLCBkaS0+ZGV2bmFt ZSwgSENJX0RFVk5BTUVfU0laRSk7CisJcmV0dXJuICgxKTsKK30KKwogc3RhdGljIGNoYXIgKgog YnRfZGV2Mm5vZGUoY2hhciBjb25zdCAqZGV2bmFtZSwgY2hhciAqbm9kZW5hbWUsIGludCBubmxl bikKIHsKSW5kZXg6IGJsdWV0b290aC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGJsdWV0b290aC5oCShyZXZp c2lvbiAxOTA1OTQpCisrKyBibHVldG9vdGguaAkod29ya2luZyBjb3B5KQpAQCAtMzksNiArMzks NyBAQAogI2luY2x1ZGUgPHN5cy9lbmRpYW4uaD4KICNpbmNsdWRlIDxzeXMvaW9jdGwuaD4KICNp bmNsdWRlIDxzeXMvc29ja2V0Lmg+CisjaW5jbHVkZSA8c3lzL3Vpby5oPgogI2luY2x1ZGUgPHN5 cy91bi5oPgogI2luY2x1ZGUgPGVycm5vLmg+CiAjaW5jbHVkZSA8bmV0ZGIuaD4KQEAgLTQ2LDYg KzQ3LDcgQEAKICNpbmNsdWRlIDxuZXRncmFwaC9ibHVldG9vdGgvaW5jbHVkZS9uZ19oY2kuaD4K ICNpbmNsdWRlIDxuZXRncmFwaC9ibHVldG9vdGgvaW5jbHVkZS9uZ19sMmNhcC5oPgogI2luY2x1 ZGUgPG5ldGdyYXBoL2JsdWV0b290aC9pbmNsdWRlL25nX2J0c29ja2V0Lmg+CisjaW5jbHVkZSA8 dGltZS5oPgogCiBfX0JFR0lOX0RFQ0xTCiAKQEAgLTEyOSwxMSArMTMxLDQ2IEBACiAJdWludDhf dAkJX3BhZGRpbmdbMjBdOwkvKiBsZWF2ZSBzcGFjZSBmb3IgZnV0dXJlIGFkZGl0aW9ucyAqLwog fTsKIAorc3RydWN0IGJ0X2RldnJlcQoreworCXVpbnQxNl90CW9nZjsKKwl1aW50MTZfdAlvY2Y7 CisJaW50CQlldmVudDsKKwl2b2lkCQkqY3BhcmFtOworCWludAkJY2xlbjsKKwl2b2lkCQkqcnBh cmFtOworCWludAkJcmxlbjsKK307CisKK3N0cnVjdCBidF9kZXZmaWx0ZXIgeworCXVpbnQ2NF90 CWV2ZW50X21hc2s7CisJdWludDhfdAkJcGFja2V0X21hc2s7Cit9OworCitzdHJ1Y3QgYnRfZGV2 aW5xdWlyeSB7CisJYmRhZGRyX3QJYmRhZGRyOworCXVpbnQ4X3QJCXBzY2FuX3JlcF9tb2RlOwor CXVpbnQ4X3QJCXBzY2FuX3BlcmlvZF9tb2RlOworCXVpbnQ4X3QJCXBzY2FuX21vZGU7CisJdWlu dDhfdAkJZGV2X2NsYXNzWzNdOworCXVpbnQxNl90CWNsb2NrX29mZnNldDsKK307CisKIHR5cGVk ZWYgaW50CShidF9kZXZlbnVtX2NiX3QpKGludCwgc3RydWN0IGJ0X2RldmluZm8gY29uc3QgKiwg dm9pZCAqKTsKIAoraW50CQlidF9kZXZvcGVuIChjaGFyIGNvbnN0ICpkZXZuYW1lKTsKK2ludAkJ YnRfZGV2Y2xvc2UoaW50IHMpOworaW50CQlidF9kZXZzZW5kIChpbnQgcywgdWludDE2X3Qgb2dm LCB1aW50MTZfdCBvY2YsIGludCBwbGVuLCB2b2lkICpwYXJhbSk7CitpbnQJCWJ0X2RldnJlY3Yg KGludCBzLCB1aW50OF90ICpidWYsIGludCBzaXplLCB0aW1lX3QgdG8pOworaW50CQlidF9kZXZy ZXEgIChpbnQgcywgc3RydWN0IGJ0X2RldnJlcSAqciwgdGltZV90IHRvKTsKK2ludAkJYnRfZGV2 ZmlsdGVyKGludCBzLCBzdHJ1Y3QgYnRfZGV2ZmlsdGVyIGNvbnN0ICpuZXcsCisJCQkgICAgIHN0 cnVjdCBidF9kZXZmaWx0ZXIgKm9sZCk7CitpbnQJCWJ0X2RldmlucXVpcnkoY2hhciBjb25zdCAq ZGV2bmFtZSwgaW50IGxlbmd0aCwgaW50IG51bV9yc3AsCisJCQkgICAgICB1aW50OF90IGNvbnN0 ICpsYXAsIHN0cnVjdCBidF9kZXZpbnF1aXJ5ICoqaWkpOwogaW50CQlidF9kZXZpbmZvIChzdHJ1 Y3QgYnRfZGV2aW5mbyAqZGkpOwogaW50CQlidF9kZXZlbnVtIChidF9kZXZlbnVtX2NiX3QgKmNi LCB2b2lkICphcmcpOwogCisKIC8qCiAgKiBiZGFkZHIgdXRpbGl0eSBmdW5jdGlvbnMgKGZyb20g TmV0QlNEKQogICovCg== --00163630f4a9f0c9e20466e929c3-- From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 9 00:44:01 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 16AA4106564A for ; Thu, 9 Apr 2009 00:44:01 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id D9D898FC12 for ; Thu, 9 Apr 2009 00:44:00 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 4E5543143C7; Wed, 8 Apr 2009 20:27:16 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 08 Apr 2009 20:27:16 -0400 X-Sasl-enc: ADgy3Y5YNAwosb32pjWLwTDka8JSKCJ+kKSMKkpOZkoW 1239236835 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 6AF7536192; Wed, 8 Apr 2009 20:27:15 -0400 (EDT) Message-ID: <49DD40E2.5030403@incunabulum.net> Date: Thu, 09 Apr 2009 01:27:14 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Maksim Yevmenkin References: <49D92E26.2030508@incunabulum.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" , "alexei@raylab.com" 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: Thu, 09 Apr 2009 00:44:01 -0000 Maksim Yevmenkin wrote: > > right, a few things. > > - dev_id is kinda gross, imo. Iain and i discussed this and agreed > that devname is the way to go. mapping between dev_id and devname can > be (has to be) done and i have no objection to this, however, all the > native api probably should use devname and not dev_id; > I agree with you here, but that doesn't change the fact that we are potentially being Betamax'd by BlueZ, even if not intentionally ;-) FYI if you are not familiar with the story of Betamax: it was the technological superior of the VHS video cassette standard, bot of course VHS got the dominant market share, and therefore won out in the end. > - all the hci_xxx functions (with possible exception of inquiry) > should probably be left out of the library. there is really not enough > consumers for them; > I disagree. I did a fairly in-depth code audit of PyBlueZ, LightBlue, and BlueCove. All of them use BlueZ hci_* APIs for a number of things, mostly to do with querying properties of the local interfaces. This might not be the case for Bluetooth daemons in the base system, and much of what is in BlueZ, is used by its daemons. Given that I've read a lot of BlueZ code now, I can't entirely claim that my implementation of the API is truly clean-room. > - i not sure i like, hci_xxx names; Iain and i have been discussing > this before and agreed that, bt_XXX and bt_devXXXX are better names; > Well, the thing is, folk have already gone off and started building high-level language APIs on top of the BlueZ C language APIs. I understand from the 'code purity' point of view why one would be keen to adopt this kind of compartmentalization in terms of naming conventions. The problem is that the horse has already left the cart. There have been books published on how to use Bluetooth from Java and other higher level languages than C. It seems unreasonable, in my view, to expect folk developing applications in a commercial model, to have to adapt their code for BSD targets beyond say 2 or 3 ifdef's. I realize this might be an inelegant approach, but it's based on observation of harsh commercial realities. > i'm attaching the diffs that was sitting in my queue (still need to > update man pages). please take a look at it and let me know what you > think. > Looks very similar in places to some of the code Markus wrote which I worked with. We certainly need an easy to use API which doesn't concern high level language users with too many of the specifics of low level I/O event handling. >> The API is now compatible with the current BlueZ SVN code. One of the >> trade-offs involved was choosing an identifier which would fit in an 'int' >> type, as BlueZ identifies its devices using uint16_t. >> >> As a compromise, I wrote code which emulates BlueZ device enumeration >> using the Netgraph node ID (32 bits wide). Unfortunately this introduces >> a dependency on -lnetgraph, unless the Bluetooth stack is itself taught to >> produce such an identifier (and supply it via an ioctl()). >> > > i actually went this route before :) but i opted for much simpler scheme: > > Thanks for this. I would far rather not introduce a runtime or link-time dependency on -lnetgraph if I can possibly avoid it. I'll digest further and try to see if this can be incorporated. > ... >> raise any other events *at all* at the HCI layer during inquiry. >> >> Mind you, I haven't tried any of the Bluetooth HCI 2.0/EDR commands, >> many of these are not yet implemented in the FreeBSD stack, am I right? >> > > well, most of 2.0 commands do not need any implementation. just need > to add defines and typedefs. some events might need handling, i.e. > inquiry with rssi. but generally it should just work. > I agree with you up to the point where 'it should just work'. A lot of what goes on with Bluetooth is actually going on behind closed doors. There are individuals (whom I won't name here to defend them from any possible litigation) who have found it necessary to disassemble what's actually going on with the 16-bit microcontrollers found in most Bluetooth devices. There have also been moves on the part of the Bluetooth SIG to make it harder to find information about Bluetooth's actual operation itself, as I am also sure you are aware. Nevertheless, that's largely orthogonal to the issues of implementing Bluetooth 2.0/EDR compatibility. What is clear is that the BlueZ API has moved with the times, and ours hasn't. My hope is that by actually using Bluetooth for interesting applications, that will help to drive interest forward. One observation I make from the current state of the BlueZ SVN code is that their primary focus is on desktop integration. If they were really serious, this work would already have been completed. As things stand, BlueZ as a platform is missing a few things which would make it easier to build Bluetooth server applications. ... Back to periodic inquiry: I am very surprised that given Bluetooth's value as a highly localized network, that the implementation of periodic inquiry, a feature pretty much essential to building endpoint discovery in a highly dynamic network environment, would tie up the whole microcontroller for the duration of the inquiry. I looked at the Bluetooth specs and I can see that the inquiry sequence doesn't hog all of the radio spectrum in use, but the implementation on the CSR dongles won't raise any other events whilst the inquiry is in progress. It's a bit of a cop out, to be sure, and we can certainly work around this by using a dedicated dongle to perform neighbor discovery. But why didn't they think about this in the spec? That begs the question. > >> I also had a crack at porting NetBSD's 'btconfig'. I haven't included it in >> this drop, however, it does depend on the libhci functions I have written. >> > > how about just fixing hcicontrol(8) do to that you want? is this too much work? > Whilst hccontrol(8) is an excellent and very complete tool, it is perhaps too complete for its own good. It captures a fairly complete set of the HCI commands normally used to manipulate Bluetooth host controller devices. However, it isn't terribly user friendly. My motivation in porting NetBSD's btconfig was more to do with the fact that it captures common use cases much like Linux BlueZ's hcitool -- i.e. folk familiar with UNIX in general become familiar with ifconfig(8), and btconfig has very similar semantics. Whilst in the FreeBSD case this isn't terribly important -- the devd.conf integration is thorough and works at boot-time just fine for building appliances -- it's not great for operational use i.e. debugging or manual config where it's needed. I would agree with the view that ifconfig(8) has become something of a kitchen sink, and whilst I wouldn't initially attempt to integrate Bluetooth functionality with that tool, I wouldn't rule it out, either. > >> I see that NetBSD's libsdp does support 128 bit UUIDs. Whilst this is >> highly desirable, it is also a prerequisite for any of the high level >> language >> wrappers (e.g. PyBlueZ, BlueCove) which make use of SDP. >> > > ok, i will take a look at the diffs to see what is different. > Yeah, talk about two arrows going in opposite directions :-) I found when hacking with BlueCove on Windows, I had to tell it *explicity* to use 16-bit UUIDs so that most phones could see the services it was advertising. The SDP story is a mess, to be sure, and could do with better APIs everywhere. What developers tend to do, in my experience, is to avoid dealing with platform specifics -- *unless they absolutely have to* -- and focus on delivering the solution with APIs that they can readily grasp. Sadly, the SDP APIs on all platforms are sorely missing this casual ease-of-use. >> Anyway, let me know what you think. I am eager to get the SDP issues >> knocked on the head ASAP. >> > > right, that would likely be complete replacement of libsdp and sdpd. > If that's what it amounts to, I'll get my hands dirty. It's just essential for what my partner and I are trying to do, that we have high-level language bindings for Bluetooth features essential to building a server application, working on FreeBSD. I am willing to help out in any way I can to drive this forward. thanks and regards, BMS From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 9 06:27:17 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 1468F106566B; Thu, 9 Apr 2009 06:27:17 +0000 (UTC) (envelope-from chuckop@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id CE57C8FC12; Thu, 9 Apr 2009 06:27:16 +0000 (UTC) (envelope-from chuckop@gmail.com) Received: by wa-out-1112.google.com with SMTP id m38so273231waf.27 for ; Wed, 08 Apr 2009 23:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version :content-disposition:message-id:content-type :content-transfer-encoding; bh=rWkHbYD6yo1Q9Mzs3xxJ6Q3SfMgin2oI1tc2paLKFOY=; b=m81kOSWqxzIAVeuBMnM2bDrl+rtjtmONhoj2W7GYdxOe24bnyeuaTNe7/ePv3w+Jjf KpGEHi6bximNtMmyu885G6xhEJpU2oRET0VC6NqjaAhM/XjwO9i1f7E2ULSDHJHkuhIR IoArmF/m5+oRGfiqBsd7zhJzDrJsenv7acz9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-disposition:message-id :content-type:content-transfer-encoding; b=KV+vbSoCOE8xEFPxHout38zsI4h5NraGLXaNw9F/Zjcaaei9D7b/PFZgT4JLxJx5B8 lnNzBMxWudpK7VB4DQkBj478mWmjLYOkV+Gr1t8AxQfvEIrCY9X7TrIMBrEFIJbjrMjR b2g5jZ+aNNnKmYDKqk4G5XOyjLqyOYL6UB4Ts= Received: by 10.115.108.1 with SMTP id k1mr1237915wam.0.1239257230046; Wed, 08 Apr 2009 23:07:10 -0700 (PDT) Received: from think.coppersoftware.com (pool-71-112-39-100.sttlwa.dsl-w.verizon.net [71.112.39.100]) by mx.google.com with ESMTPS id z15sm731709pod.18.2009.04.08.23.07.07 (version=SSLv3 cipher=RC4-MD5); Wed, 08 Apr 2009 23:07:09 -0700 (PDT) From: Charles Oppermann Organization: Copper Software To: freebsd-bluetooth@freebsd.org Date: Wed, 8 Apr 2009 23:07:00 -0700 User-Agent: KMail/1.9.10 References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> In-Reply-To: <49DD40E2.5030403@incunabulum.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200904082307.01454.chuckop@gmail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: "alexei@raylab.com" , Bruce Simpson , Maksim Yevmenkin 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: Thu, 09 Apr 2009 06:27:17 -0000 On Wednesday 08 April 2009 5:27:14 pm Bruce Simpson wrote: > I agree with you here, but that doesn't change the fact that we are > potentially being Betamax'd by BlueZ, even if not intentionally ;-) > > FYI if you are not familiar with the story of Betamax: it was the > technological superior of the VHS video cassette standard, bot of > course VHS got the dominant market share, and therefore won > out in the end. Common misconception. The Betamax was only marginally of better quality, and any differences were not discernable to consumers. People bought VHS-format VCR's because the first publically available recorders could record up to go 2 hours, vs. Sony's 1 hour maximum for Betamax. When the major use of VCR's was to record movies off of cable for repeated viewings, the recording time was a major factor. Every time Sony came up with longer recording times, JVC and RCA would stay ahead. Sony tried very hard to position Betamax as the higher quality alternative, but Sony's 2-hour long tapes made the same compromises as VHS did. SuperBeta tapes were higher quality than VHS, but the format war was over by the time they were available along with recorders. From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 9 08:01:32 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 34EDB106567C for ; Thu, 9 Apr 2009 08:01:32 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id B35248FC1B for ; Thu, 9 Apr 2009 08:01:31 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.t-mobile.co.uk with esmtp (Exim 4.50) id 1LrpCQ-0000cr-Nn; Thu, 09 Apr 2009 09:01:26 +0100 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02199-08; Thu, 9 Apr 2009 09:01:26 +0100 (BST) Received: from [10.214.101.225] (helo=rya-online.net) by localhost.t-mobile.co.uk with smtp (Exim 4.50) id 1LrpCI-0000cY-Dj; Thu, 09 Apr 2009 09:01:26 +0100 Received: (nullmailer pid 507 invoked by uid 1000); Thu, 09 Apr 2009 08:00:03 -0000 Date: Thu, 9 Apr 2009 09:00:03 +0100 (BST) To: Bruce Simpson In-Reply-To: <49DD40E2.5030403@incunabulum.net> References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1239264003.862926.638.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 localhost.t-mobile.co.uk); SAEximRunCond expanded to false Cc: "freebsd-bluetooth@freebsd.org" 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: Thu, 09 Apr 2009 08:01:44 -0000 On Thu, 9 Apr 2009, Bruce Simpson wrote: > I disagree. I did a fairly in-depth code audit of PyBlueZ, LightBlue, and > BlueCove. All of them use BlueZ hci_* APIs for a number of things, mostly > to do with querying properties of the local interfaces. I looked briefly at BlueCove the other day and it seems to use a module to interface with the BlueZ/Linux API but it also has Windows and Mac modules amongst others. If it needs a FreeBSD or NetBSD module then that doesn't seem so difficult? I looked at LightBlue but I don't remember anything about it, was it perchance really incomplete and very BlueZ/Linux based? > The problem is that the horse has already left the cart. That happened many years ago when Microsoft was the leader in the marketplace. If you want to stay with the horse, use Windows. > There have been books published on how to use Bluetooth from Java and > other higher level languages than C. It seems unreasonable, in my view, > to expect folk developing applications in a commercial model, to have to > adapt their code for BSD targets beyond say 2 or 3 ifdef's. so write a module that interfaces (for example) the Java (BlueCove?) API to the FreeBSD OS layer. Its not that different from the BlueZ/Linux API and you can probably just do some copy and paste work. Thats how the GPL world works. Yes, you will not be able to integrate that work directly into FreeBSD but then I doubt a Java interface is ever going to be accepted into base anyway. Donate it to BlueCove. > I realize this might be an inelegant approach, but it's based on > observation of harsh commercial realities. If its commercial, get those companies to contribute some BSD code. > We certainly need an easy to use API which doesn't concern high level > language users with too many of the specifics of low level I/O event > handling. as you say, the Java API is one such. > Thanks for this. I would far rather not introduce a runtime or link-time > dependency on -lnetgraph if I can possibly avoid it. I'll digest further > and try to see if this can be incorporated. But I thought, on FreeBSD the whole bluetooth stack is netgraph based..? 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. The BlueZ guys are, I think, working on a dbus API that will be used by GNOME and KDE and hopefully it won't be tied to the Linux OS API so closely, so that we can write dbus modules and have applications just work on our OS. I have not been providing any input or review of that API though, it would be good if somebody would step up and point out where the API is tied too closely to the Linux OS interface and get them to make it a bit more generic. > I looked at the Bluetooth specs and I can see that the inquiry sequence > doesn't hog all of the radio spectrum in use, but the implementation on > the CSR dongles won't raise any other events whilst the inquiry is in > progress. Is this purely a CSR problem? My laptop has a Broadcom chip in and I notice that it can make multiple connections concurrently in that on bootup, it connects to both my mouse and keyboard by itself sometimes - the CSR dongle I used previously would connect to the keyboard fine but always fail the second connect with "Command Disallowed". So much so that I thought perhaps about serialising connection attempts in the kernel. I've never looked at periodic inquiry though.. > > right, that would likely be complete replacement of libsdp and sdpd. > > If that's what it amounts to, I'll get my hands dirty. It's just > essential for what my partner and I are trying to do, that we have > high-level language bindings for Bluetooth features essential to > building a server application, working on FreeBSD. I have written at least a set of SDP primitives that I'm intending to import to NetBSD 'soon' (I have only one computer and am concentrating on 5.0 release first because running different OS versions is messy) I think the latest archive was at http://www.netbsd.org/~plunky/sdp-20090227.tar.gz iain From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 9 17:13:25 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 91E37106564A for ; Thu, 9 Apr 2009 17:13:25 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id 458808FC0C for ; Thu, 9 Apr 2009 17:13:25 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk24 with SMTP id 24so2032739gxk.19 for ; Thu, 09 Apr 2009 10:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WR4ZKDL7aRnvNJ+x4T17Na0mEGDqmXjJkUDZ5X3qijg=; b=DArTwRCk+AathFr6W/RxBsJmuqtazlD3FdqQUic8GJzWWQ02Xa4fqWfR0Eu+hGHXRP uwRlXwy65B9xCvjReSl30DDMQGpske/u8cIN9iwI/Z5Wrv+YtyiZ8oB+lorn08H1zZul Xw7jN19tvdGem7q5qjEoFjfI3Pa4YxsIZrF0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mZPu0h/mKetbCXfvFjAE+DblfGqsjbS6RjIUdrgrs36iWJEgNhGNWtlyxFvqMo8Uat oMAMNmP42BGGLr0LkkZofGtyoAbFE1FVDlrXRxTP/afKDXi2o2k8Ql10evj6GrWF8fN0 TUnVLkFovlHsWxycV+MLl+W2tFeEXOP4vxxbA= MIME-Version: 1.0 Received: by 10.90.105.6 with SMTP id d6mr3266227agc.70.1239297204337; Thu, 09 Apr 2009 10:13:24 -0700 (PDT) In-Reply-To: <1239264003.862926.638.nullmailer@galant.ukfsn.org> References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> Date: Thu, 9 Apr 2009 09:13:24 -0800 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" , 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: Thu, 09 Apr 2009 17:13:25 -0000 On Thu, Apr 9, 2009 at 12:00 AM, Iain Hibbert wrote: > On Thu, 9 Apr 2009, Bruce Simpson wrote: > >> I disagree. I did a fairly in-depth code audit of PyBlueZ, LightBlue, and >> BlueCove. All of them use BlueZ hci_* APIs for a number of things, mostly >> to do with querying properties of the local interfaces. > > I looked briefly at BlueCove the other day and it seems to use a module to > interface with the BlueZ/Linux API but it also has Windows and Mac modules > amongst others. If it needs a FreeBSD or NetBSD module then that doesn't > seem so difficult? right, that is something i kinda wondering too. of course, i have no idea how hard it would be to plug new bluetooth module into bluecove. perhaps cost of adding the new bluetooth module more than implementing something that looks like bluez? >> The problem is that the horse has already left the cart. > > That happened many years ago when Microsoft was the leader in the > marketplace. If you want to stay with the horse, use Windows. the real question is: do we really want to follow the horse? :) personally, i think that we should keep an eye on bluez etc. to see where its going, but blindly follow it, is not something we want to do, imo, 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: 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. 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. >> There have been books published on how to use Bluetooth from Java and >> other higher level languages than C. It seems unreasonable, in my view, >> to expect folk developing applications in a commercial model, to have to >> adapt their code for BSD targets beyond say 2 or 3 ifdef's. > > so write a module that interfaces (for example) the Java (BlueCove?) API > to the FreeBSD OS layer. Its not that different from the BlueZ/Linux API > and you can probably just do some copy and paste work. Thats how the GPL > world works. Yes, you will not be able to integrate that work directly > into FreeBSD but then I doubt a Java interface is ever going to be > accepted into base anyway. Donate it to BlueCove. well, it depends on how hard it is to add such module. i can certainly see and understand yours and Bruce's point. >> I realize this might be an inelegant approach, but it's based on >> observation of harsh commercial realities. > > If its commercial, get those companies to contribute some BSD code. oh, well, sometimes it is not as easy as it sounds. >> Thanks for this. I would far rather not introduce a runtime or link-time >> dependency on -lnetgraph if I can possibly avoid it. I'll digest further >> and try to see if this can be incorporated. > > 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. > 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). > The BlueZ guys are, I think, working on a dbus API that will be used by > GNOME and KDE and hopefully it won't be tied to the Linux OS API so > closely, so that we can write dbus modules and have applications just work > on our OS. I have not been providing any input or review of that API > though, it would be good if somebody would step up and point out where the > API is tied too closely to the Linux OS interface and get them to make it > a bit more generic. right, and that is a very good point. that is something that i have to deal with every day at $realjob. things in linux world change very rapidly. from commercial point of view it is very annoying. its not that uncommon that entire subsystems are being thrown away and re-written from scratch without too much consideration. that is why i think having a separate libhci/ port is making more sense here. >> I looked at the Bluetooth specs and I can see that the inquiry sequence >> doesn't hog all of the radio spectrum in use, but the implementation on >> the CSR dongles won't raise any other events whilst the inquiry is in >> progress. > > Is this purely a CSR problem? My laptop has a Broadcom chip in and I > notice that it can make multiple connections concurrently in that on > bootup, it connects to both my mouse and keyboard by itself sometimes - > the CSR dongle I used previously would connect to the keyboard fine but > always fail the second connect with "Command Disallowed". So much so that > I thought perhaps about serialising connection attempts in the kernel. 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. as far as periodic inquiry goes, its probably not the rf spectrum hogging. its probably related to the way hardware and/or link manager is implemented, i.e. from specification A unit that wants to discover other Bluetooth units enters an inquiry substate. In this substate, it continuously transmits the inquiry message (which is the ID packet, see Section 4.4.1.1 on page 55) at different hop frequencies. The inquiry hop sequence is always derived from the LAP of the GIAC. Thus, even when DIACs are used, the applied hopping sequence is generated from the GIAC LAP. the key thing is that device has to continuously transmits the inquiry message at different hop frequencies. at the same time the same device may participate in another connection (which may require hopping as well). > I've never looked at periodic inquiry though.. me too. but now i'm interested :) thanks max From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 9 18:40:55 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 DC78F106564A for ; Thu, 9 Apr 2009 18:40:54 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id AB8CA8FC14 for ; Thu, 9 Apr 2009 18:40:54 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 27F50315518; Thu, 9 Apr 2009 14:40:54 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 09 Apr 2009 14:40:54 -0400 X-Sasl-enc: 1GUgjdTnF4qpjNuSFZLOd8o06yS4uXVn6OfSUxx3szYD 1239302453 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4ECE44C02A; Thu, 9 Apr 2009 14:40:53 -0400 (EDT) Message-ID: <49DE4134.9060604@incunabulum.net> Date: Thu, 09 Apr 2009 19:40:52 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Iain Hibbert References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> In-Reply-To: <1239264003.862926.638.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" , "alexei@raylab.com" 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: Thu, 09 Apr 2009 18:40:55 -0000 Hi guys, I really hate to be long-winded with this... but it seems there are a number of thorny issues in the Bluetooth area which we need to carefully consider and act upon going forward. Iain Hibbert wrote: > I looked briefly at BlueCove the other day and it seems to use a module to > interface with the BlueZ/Linux API but it also has Windows and Mac modules > amongst others. If it needs a FreeBSD or NetBSD module then that doesn't > seem so difficult? > I had literally spent two evenings before staring at PyBluez/LightBlue/BlueCove code on my ThinkPad, whilst lying on my mother's sofa, and after hacking MLDv2 into FreeBSD-CURRENT's IPv6 stack. When I hacked on libhci I was on a train from Glasgow to London last Thursday evening, and let me tell you, I was staring at KScope a lot! Of course it's also to do with the fact that BlueZ libhci is an API which is being used by a number of apps out there, so I had more example material to work from, having waded into this knowing NOTHING about the existing APIs. If you look at the differences between netbt, FreeBSD bluetooth, and BlueZ, it's ifdef city. Nothing is all that different under the hood in terms of meaning, or role within the stack, but every possible thing is named differently. In terms of porting/compatibility, my focus has been on developing shims for the BlueZ API, given its relative wide adoption in the open source software available for Bluetooth, rather than hacking BSD native support code, as this just seemed like the quicker path towards my goal: Python support for building Bluetooth server apps, on a FreeBSD based system. I also wanted to minimize the diff sets required for interoperability. In my experience, the smaller patches are, the more likely third parties are to take them on upstream. > I looked at LightBlue but I don't remember anything about it, was it > perchance really incomplete and very BlueZ/Linux based? > Yes, LightBlue is actually quite incomplete, although it is intended to be dog simple. Some technical detail follows: LightBlue relies on PyBlueZ as a prerequisite, and uses a handful of libhci functions, as well as requiring OpenOBEX. It is also GPLv3'd which is off-putting to say the least for commercial use. Trouble is, PyBlueZ is actually very tied to some BlueZ specifics, i.e. the HCI interface in particular. Any time we need to reach down to baseband, which you end up doing to implement neighbor discovery, you need to use HCI. SDP alone just doesn't cut it; paging every device in the immediate vicinity is quite an expensive operation. It is the only Python native binding I know of which ties OBEX on top of Bluetooth in a similar way to that of Java JSR-82's 'SessionNotifier' interface -- which is what we really need for building Bluetooth server apps. We found Python's HTTPServer very useful indeed, and having something like an OBEXServer would be just right for us. However, LightBlue has the limitation that it doesn't have any support for multiple devices/enumeration, unless you go directly to PyBlueZ, and doesn't support a event driven interface for Bluetooth server apps -- its APIs are strictly synchronous function calls. Same for its OBEXClient class, however at least that can have some methods overridden, but still isn't as flexible as we would like it to be. To be fair, it isn't a lot of code, and implementing a new Python API similar to LightBlue would not take too much time, provided the foundations are in place. The real fly in the soup is the fact that the BlueZ bindings I've seen, are all tied to BlueZ's use of a 16 bit wide identifier for each local Bluetooth device in device enumeration. These end up leaking into the APIs. That's just unavoidable, as it is still reasonable that there is a means of referring to devices without opening them. In an ideal world we'd be able to use a string identifier, but that is not what's happened NOW. JSR-82 is less tied up in this way, but it still assumes that there is an integer device ID unique to each local device which will fit in a Java JNI jint type. ... To summarize: I'm just concerned that in focusing too much on building a clean / BSD native API, we risk sidelining ourselves. There has been a lot of Bluetooth activity in the Linux community, and by not having at least some degree of source level compatibility, we risk not being able to leverage and make use of that work which we could otherwise benefit from for small change cost. There is no 'standard' for high level Bluetooth APIs that I am aware of, other than JSR-82, and wider adoption of a platform tends to wind up with it being 'de-facto' standard. Whether we like it or not, it's a harsh reality of software work. Hence my comparison to Betamax/VHS in my original reply. I myself, I just get sick and tired of having to HACK HACK HACK every time someone writes a neato little app for BlueZ. This situation is endemic simply because Linux has a popularity which the BSDs don't, as such it can potentially attract a greater number of folk getting into software dev for the first time, or on a hobbyist basis. I realize that this might be an unpopular view in the BSD camp, but that is how it looks from where I'm standing. [I've been living on the edge with this stuff for months, and I really just want to make progress so I can focus on more fun things in life than fscking computers!!] > so write a module that interfaces (for example) the Java (BlueCove?) API > to the FreeBSD OS layer. Its not that different from the BlueZ/Linux API > and you can probably just do some copy and paste work. Thats how the GPL > world works. Yes, you will not be able to integrate that work directly > into FreeBSD but then I doubt a Java interface is ever going to be > accepted into base anyway. Donate it to BlueCove. > Well, that's exactly my point, I am not for one moment suggesting we fold JSR-82 into any base system... but time is critical and we need to work with what's already there, unless someone comes up with a compelling alternative NOW. > If its commercial, get those companies to contribute some BSD code. > That's a reasonable statement, but for the fact that... ...The companies either don't exist or are potential competitors who aren't using BSD or Linux -- or, WE are the potential companies! My partner and I are already working on this, so it is very much a matter of beg borrow or steal. There seems no sense, to my mind, in reinventing wheels... There are competing interests in this space, but they've had the CapEx to go off and implement their own platforms. As to the business end of it, whether that's a tax write-off for investment purposes I know and care not, it's just what any new player would be up against in the Bluetooth space. > >> Thanks for this. I would far rather not introduce a runtime or link-time >> dependency on -lnetgraph if I can possibly avoid it. I'll digest further >> and try to see if this can be incorporated. >> > > But I thought, on FreeBSD the whole bluetooth stack is netgraph based..? > It is, but generally the libbluetooth / libsdp libraries 'get away' with not touching Netgraph directly, as the Netgraph ng_btsocket node exposes a number of socket options and ioctls which require no knowledge/linkage to Netgraph in order to use. I just ended up going to Netgraph to perform BlueZ style device enumeration, which needs an integer handle (a bit like an ifnet ifindex in the network stack), rather than a textual name. The code which Maksim posted would help us to side step this in any prospective libhci compatibility library. > 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. > Sure, but I don't have free time to come up with such a higher level API, and as such, I need to work with what's already out there. Of course, if anyone else is willing to volunteer to work on this, they are more than welcome to do so, but the problem with assembling a product / strategy based on that, is, we need to know how much it's going to cost, and how much time it's going to take, i.e. when will it be ready. Hence my interest in leveraging what is already out there *NOW*. It is in no way a technical or political endorsement of any particular approach, camp, product, or philosophy, it is a purely pragmatic approach to the reality of working with limited resources and time. :-) As I say, I'm not trying to tread on anyone's toes, or otherwise rule out good and technically valid solutions. We just needed this thing months ago and it's not there. > The BlueZ guys are, I think, working on a dbus API that will be used by > GNOME and KDE and hopefully it won't be tied to the Linux OS API so > closely, so that we can write dbus modules and have applications just work > on our OS. I have not been providing any input or review of that API > though, it would be good if somebody would step up and point out where the > API is tied too closely to the Linux OS interface and get them to make it > a bit more generic. > Yes they are, however, as I've hinted at before, they seem focused on this and little else. Back in January my colleague Alexei (Cc'd)and I did some work with the latest BlueZ bluetoothd frm SVN. We were astonished and dismayed to find that operations critical to the receiving of files had completely changed, i.e. the 'inquiry scan' setting, and the documentation had not been updated. Whilst we had discovered and found the problem, and documented a workaround, we had a demo suffer from a technical hitch because of this issue. Of course, it is fair to argue that we get what we deserve for trying to work with the bleeding edge of development. However, this wasn't just a few minor changes, the entire configuration mechanism had been rewritten, with no documentation other than the code. I could care less about Linux or BSD specifics at this point. If folk want to create new APIs, please do so -- I ain't stopping you! And if I can help out, I will. I'm certainly receptive to everyone's ideas here given their technical merit, but it should be borne in mind that we have a very specific goal. > >> I looked at the Bluetooth specs and I can see that the inquiry sequence >> doesn't hog all of the radio spectrum in use, but the implementation on >> the CSR dongles won't raise any other events whilst the inquiry is in >> progress. >> > > Is this purely a CSR problem? My laptop has a Broadcom chip in and I > notice that it can make multiple connections concurrently in that on > bootup, it connects to both my mouse and keyboard by itself sometimes - > the CSR dongle I used previously would connect to the keyboard fine but > always fail the second connect with "Command Disallowed". So much so that > I thought perhaps about serialising connection attempts in the kernel. > I doubt that the issue with inquiry tying up the controller is limited to CSR dongles, but it's one area where we either need to engage the vendor directly and ask them what the story is, or conduct experiments to map out the behaviour in the time domain amongst different vendors and models (very time consuming). If you look at the specs, inquiry keeps the controller quite busy. There are several different inquiry variants, and they all involve frequency hopping, and the transmission of the inquiry sequence. It's mostly baseband stuff and doesn't involve e.g. L2CAP layer. The inquiry sub-state, as described in the spec, doesn't preclude other HCI events during the inquiry, however it does recommend that ACL transports be parked, as it only reserves slots for SCO. I haven't delved deep enough to see if FreeBSD Bluetooth is doing ACL park when periodic inquiry is active, I wager it doesn't, and what we're actually seeing is the client device attempting to reconnect after the inquiry sub-state is left, after seeing no reply. > I've never looked at periodic inquiry though.. > Periodic inquiry is basically the same as regular inquiry, with the exception that the periodic timer is hosted by the microcontroller itself. When the timer fires, it will drop just about everything else that it's doing, mind you I've seen with OBEX sessions running at the same time, it will either pick them up once inquiry has finished, or finish the OBEX session (RFCOMM) before starting inquiry. Of course given that it will not generate any event upcall at HCI layer for any other baseband protocol event during the inquiry, it's of very limited usefulness for real apps. The only application I've seen which uses it is the Bluetooth scanner/sniffer/brute forcer 'Fine Tooth Comb' from shmoo.com. > I have written at least a set of SDP primitives that I'm intending to > import to NetBSD 'soon' (I have only one computer and am concentrating on > 5.0 release first because running different OS versions is messy) > > I think the latest archive was at > http://www.netbsd.org/~plunky/sdp-20090227.tar.gz > Thanks for this, I'll be sure to take a look once I can download it. I don't seem to be able to reach www.netbsd.org at the moment, either from my home ISP connection, or from freefall.freebsd.org. :-( I am very grateful for your input and feedback, and hope that we can get this ball rolling faster. cheers, BMS From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 9 19:36:21 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 4A6BD106566C for ; Thu, 9 Apr 2009 19:36:21 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 18BDF8FC1D for ; Thu, 9 Apr 2009 19:36:20 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 77630314E54; Thu, 9 Apr 2009 15:36:20 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 09 Apr 2009 15:36:20 -0400 X-Sasl-enc: 6p0zKIQUpSPvOYLB9w+PxKRI/0x97B1OfSBQlW3cW2Yl 1239305779 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 67A932DAC2; Thu, 9 Apr 2009 15:36:19 -0400 (EDT) Message-ID: <49DE4E2F.2000805@incunabulum.net> Date: Thu, 09 Apr 2009 20:36:15 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Maksim Yevmenkin References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" , "alexei@raylab.com" 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: Thu, 09 Apr 2009 19:36:21 -0000 Maksim Yevmenkin wrote: > On Thu, Apr 9, 2009 at 12:00 AM, Iain Hibbert wrote: > >> I looked briefly at BlueCove the other day and it seems to use a module to >> interface with the BlueZ/Linux API but it also has Windows and Mac modules >> amongst others. If it needs a FreeBSD or NetBSD module then that doesn't >> seem so difficult? >> > > right, that is something i kinda wondering too. of course, i have no > idea how hard it would be to plug new bluetooth module into bluecove. > perhaps cost of adding the new bluetooth module more than implementing > something that looks like bluez? > That's exactly the question I set about reading code in order to answer. The short version is, yes, in my opinion it's easier to just crib the existing APIs rather than rewrite the OS support code for all of these higher layer Bluetooth APIs completely from scratch. Dealing with JNI code can be a bit messy. I don't do Java on a daily basis so I'm less inclined to get my hands dirty with ant build.xml files. Other folks' mileage may vary. > > 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. I would hope to do the same for libsdp. > 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. 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. Also, hardcore C/C++ comms software developers are not folk you can just pick up on a recruitment milk round. ;-) Accessibility is paramount. Projects like PyBlueZ already go far towards achieving this goal, which is why they are important. It's much easier to prototype, test, and design in Python, than it is in C. The development cycle is much shorter. > 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. Some Linux-related projects have had something of a poor track record as regards change control and versioning of APIs. Yes, they do push further and faster, but we are then left with a legacy of kludge, much like GLIBC, which just gets in the way when trying to deliver product. 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. >> 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. Of course, persistence of the identifier between reboots / changes is a whole other matter -- and it affects e.g. Ethernet interfaces too. 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. > >> 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. ... re DBus: > right, and that is a very good point. that is something that i have to > deal with every day at $realjob. things in linux world change very > rapidly. from commercial point of view it is very annoying. its not > that uncommon that entire subsystems are being thrown away and > re-written from scratch without too much consideration. that is why i > think having a separate libhci/ port is making more sense here. > That is exactly the barrier which Alexei and I ran head first into back in January, when we seriously started looking at this space. Again, the chaotic approach will let one push forward thick and fast, but it doesn't always yield the best long term result. As I say, I haven't had time to look at the DBus integration to figure out in which respects it differs, or is Linux/BlueZ specific. The BlueZ project team focus at the moment seems to be on DBus. What is clear is that the KDE bluetooth subsystem had to be completely rewritten for the new DBus semantics. ... > 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. This is another reason why Iain's suggestion that we appeal to such companies to contribute BSD code may fall down -- the chances are, if they are looking to dominate the space, they have probably already invested in proprietary OS solutions for building platforms. Although I certainly can't speak for Iain's relationship with Itronix, I am most interested and curious about their reasons for diving into the Bluetooth space, and why NetBSD of all platforms ;-) ...given who their main customer base is. Also, there has been a movement in terms of strategy by technology companies to adopt GPLv2 as an alternative, not because they believe it gives them some open source credibility, although that is part of the smokescreen sometimes -- more because the terms of the GPLv2 force potential competitors to give you their code, if they derive their work from yours. That isn't cut and dried fact, it's just based on observation of who is doing what and why. > as far as periodic inquiry goes, its probably not the rf spectrum > hogging. its probably related to the way hardware and/or link manager > is implemented, i.e. from specification > ... > > the key thing is that device has to continuously transmits the inquiry > message at different hop frequencies. at the same time the same device > may participate in another connection (which may require hopping as > well). > Yup, please see my other recent reply to Iain where I noted down the bit in the specs about it being *suggests* that ACLs are held/parked/sniffed, however, the spec does not make this mandatory -- except for eSCO frames, which have reserved time slots at the Bluetooth baseband layer. 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. cheers, BMS From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 9 19:40:55 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 7E16A1065676 for ; Thu, 9 Apr 2009 19:40:55 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 4E36E8FC2F for ; Thu, 9 Apr 2009 19:40:55 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id B5C31314852; Thu, 9 Apr 2009 15:40:54 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 09 Apr 2009 15:40:54 -0400 X-Sasl-enc: vWK4hxXQLIyFxPa3MhNJmcFGvZtMY/3+44jrHs2jRPmf 1239306054 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 007B127486; Thu, 9 Apr 2009 15:40:53 -0400 (EDT) Message-ID: <49DE4F44.8070707@incunabulum.net> Date: Thu, 09 Apr 2009 20:40:52 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: "freebsd-bluetooth@freebsd.org" References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "alexei@raylab.com" Subject: Speeding up device discovery: paper 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: Thu, 09 Apr 2009 19:40:55 -0000 Hi all, I found this paper an interesting skim, even if only for the numbers and timings: http://faculty.cs.byu.edu/~knutson/publications/IrDA_Assisted_BT_Discovery.pdf It is very much a rehash of the old broadcast vs point-to-point dichotomy. I don't think IrDA is the answer for most deployments, but it's an interesting piece of research as it sheds light on how the discovery mechanisms operate (without having to read the entire specification), and how these might be sped up or worked around. I keep wishing Bluetooth had passive scanning like 802.11 does. cheers... BMS From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 9 20:37:04 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 77F0D1065670 for ; Thu, 9 Apr 2009 20:37:04 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id 27E078FC1D for ; Thu, 9 Apr 2009 20:37:04 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk24 with SMTP id 24so2287416gxk.19 for ; Thu, 09 Apr 2009 13:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=naAjSpXGUX7tDnJvdLtuW5NUhHEkHFHWGkMoUoTRnKw=; b=XAro0c7cY6vIlmXF/EZAzVoqYQ0rSxOE3PvCaWyaC/P0MLzjZ0K15hlIWG+nFglTqC w/rXvrcDMorP265DyaN8Qv3aGFdlhxFZapyGyYFOm2osmAZGlE4UKKB4SAbtyXfPsfKK g/nwSToYnGstdQhF8jAnb1c+dDSWuIu+udIQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=E8E+1ZPTQIwP3Kzd9T1FTzjoQKAyxV3csM2IAVpCTmnPs+6CoHB8jxXba8q7UAAURI u7fCQ7teMGjWOvFiTD7rZBEQwRRl891NANH9e9QOoFWnzqPY1ytvgFjqld5G/3gVIisN RI0nEOdVxExKyRFeQZvB9/PkxopX6yC1xvaKk= MIME-Version: 1.0 Received: by 10.90.49.3 with SMTP id w3mr3479563agw.44.1239309423573; Thu, 09 Apr 2009 13:37:03 -0700 (PDT) In-Reply-To: <49DE4E2F.2000805@incunabulum.net> References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <49DE4E2F.2000805@incunabulum.net> Date: Thu, 9 Apr 2009 12:37:03 -0800 Message-ID: From: Maksim Yevmenkin To: Bruce Simpson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" , "alexei@raylab.com" 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: Thu, 09 Apr 2009 20:37:04 -0000 On Thu, Apr 9, 2009 at 11:36 AM, Bruce Simpson 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 From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 9 21:11:30 2009 Return-Path: Delivered-To: bluetooth@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30DEE1065670 for ; Thu, 9 Apr 2009 21:11:30 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.freebsd.org (Postfix) with ESMTP id C2BC98FC0A for ; Thu, 9 Apr 2009 21:11:29 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.14.3/8.14.3) with ESMTP id n39Kl9Is021113 for ; Thu, 9 Apr 2009 16:47:10 -0400 (EDT) (envelope-from mi+thun@aldan.algebra.com) Message-ID: <49DE5ECD.8020202@aldan.algebra.com> Date: Thu, 09 Apr 2009 16:47:09 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.21 (X11/20090407) MIME-Version: 1.0 To: bluetooth@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: per-user directories for obexapp-server 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: Thu, 09 Apr 2009 21:11:30 -0000 Hello! I was able to set up the Bluetooth-server on my main machine, but all of the pushed files (Object Pushed) end up in the same root-only directory... Is there, perhaps, a way to specify a different directory for each device-ID (bdaddr)? This way my wife and myself could have our own locations (under home-directories somewhere) for pictures and phonebook backups... Please, advise. Thanks! Yours, -mi P.S. Maybe, the hcsecd.conf's syntax can be extended to (optionally) provide the username associated with each listed device? From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 9 21:48:54 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 949D0106566B for ; Thu, 9 Apr 2009 21:48:54 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 627B38FC20 for ; Thu, 9 Apr 2009 21:48:54 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id EBEFB31510C; Thu, 9 Apr 2009 17:48:53 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 09 Apr 2009 17:48:54 -0400 X-Sasl-enc: WaLrb6+lxpvCmUKbXivvfXdn3d/Y/r3G19Tmhs3P0c1z 1239313733 Received: from [192.168.5.236] (unknown [81.168.51.182]) by mail.messagingengine.com (Postfix) with ESMTPSA id CE877278F8; Thu, 9 Apr 2009 17:48:52 -0400 (EDT) Message-ID: <49DE6D42.6000004@incunabulum.net> Date: Thu, 09 Apr 2009 22:48:50 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Maksim Yevmenkin References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <49DE4E2F.2000805@incunabulum.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" , "alexei@raylab.com" 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: Thu, 09 Apr 2009 21:48:54 -0000 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. From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 9 22:37:01 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 C03BF1065670 for ; Thu, 9 Apr 2009 22:37:01 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id 612918FC13 for ; Thu, 9 Apr 2009 22:37:01 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk24 with SMTP id 24so2419126gxk.19 for ; Thu, 09 Apr 2009 15:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=fzHYgC9wvP5OPNgODx1BGs3YEjdllX3Z6lPpelflkBM=; b=n6Z7vInPDdxgFfrMGIl02Okj/VIbU5HabU1js73Z6BHhxuI2UcfQpHfpnlmVSs5BKH lPUo/DKgyMWKBRmEbFvgNuGGsXy5FJR92N/gpBJ4nTCMC6bkmQy2l7q647GSmJ5qMKht udiXFOsVrKidLvNquFDsx5QYU9aZyhpneahMA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XzK7TA3i4egU0h/fi7+zYu4MIqHK6LJiSDDJWV39xGPKwG3hzXjYTNBrJUHVz9I+sk 5Gu+7c3fnktm8LQm8IfAzsxRmhm9YaMpuHBVpfaW8tjf5SBZKA84JS3+ih36YaktvlSC 5j8B/2Z6+YjknpPMT4Df8BqPF1m0ItEyMYhOE= MIME-Version: 1.0 Received: by 10.90.31.8 with SMTP id e8mr3570162age.102.1239316620542; Thu, 09 Apr 2009 15:37:00 -0700 (PDT) In-Reply-To: <49DE6D42.6000004@incunabulum.net> References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <49DE4E2F.2000805@incunabulum.net> <49DE6D42.6000004@incunabulum.net> Date: Thu, 9 Apr 2009 14:37:00 -0800 Message-ID: From: Maksim Yevmenkin To: Bruce Simpson Content-Type: multipart/mixed; boundary=001636164aa7ee85e0046726e214 Cc: "freebsd-bluetooth@freebsd.org" , "alexei@raylab.com" 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: Thu, 09 Apr 2009 22:37:02 -0000 --001636164aa7ee85e0046726e214 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Apr 9, 2009 at 1:48 PM, Bruce Simpson wrote: [...] >>> 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. 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. i just dont get why any application has to know about uuid's, sequences and other low level sdp stuff just to register the damn service. that is why i went an extreme route (a bit too extreme perhaps :) and introduced "pre-cooked" sdp records that are constructed on the fly. application only transfers minimum information required to register the service. the downside, of course, is that its not very flexible. in fact, its pretty damn rigid. which means that if you want to introduce new profile, you have to change sdp parts as well. Iain and i beat this horse to death, imo. we think there is really no good way around this and we can only improve api to be more user friendly and require less typing, but the records, unfortunately, would have to be in on-the-wire format (or something pretty damn close to it). > 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? yes, we can. i was actually thinking to merge add the sdp stuff into libbluetooth. and while i'm at it, move bluetooth.h and sdp.h into include/bluetooth/ where it belongs. i just want to get hci stuff out the way first. > 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. if we fix our sdp first to be more like bluez (i.e. use on-the-wire format) then we can add compat bluez sdp library that would simply translate bluez call to bsd calls. same route as with libhci. [....] >> 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. thanks! i have attached the latest diff. its pretty much the same as previous one, except i added documentation. > [ioctls] >> >> let me know what is missing and i will add it :) > > What's the easiest way to get the unit number? > ... hci nodes do not really have unit numbers. they have names. hci nodes are named as "device+unit+hci". device + unit comes from driver for a particular device. in 99% of the cases it will be "ubtX", i.e. usb dongle, but we also support h4 devices (currently broken due to new tty) and btccc - 3com pccard. 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. >> 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? [....] >> 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. just a stupid idea - "hash" devname into devid? where "hash" does not necessarily means use some real hash function :) could be partitioning function (as in my previously posted code). how wide is devid, you mentioned that it could be as narrow as unit16 and as wide as int? is that correct? thanks, max --001636164aa7ee85e0046726e214 Content-Type: text/plain; charset=US-ASCII; name="bluetooth.hci.diff.txt" Content-Disposition: attachment; filename="bluetooth.hci.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ftc01ckq0 SW5kZXg6IGhjaS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGhjaS5jCShyZXZpc2lvbiAxOTA4NzApCisrKyBo Y2kuYwkod29ya2luZyBjb3B5KQpAQCAtMzAsMTUgKzMwLDQyMSBAQAogICogJEZyZWVCU0QkCiAg Ki8KIAorI2luY2x1ZGUgPGFzc2VydC5oPgogI2luY2x1ZGUgPGJsdWV0b290aC5oPgogI2luY2x1 ZGUgPHN0ZGlvLmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CiAj aW5jbHVkZSA8dW5pc3RkLmg+CiAKK3N0YXRpYyBpbnQgICAgYnRfZGV2YW55X2NiKGludCBzLCBz dHJ1Y3QgYnRfZGV2aW5mbyBjb25zdCAqZGksIHZvaWQgKnhkZXZuYW1lKTsKIHN0YXRpYyBjaGFy ICogYnRfZGV2Mm5vZGUgKGNoYXIgY29uc3QgKmRldm5hbWUsIGNoYXIgKm5vZGVuYW1lLCBpbnQg bm5sZW4pOwogCiBpbnQKK2J0X2Rldm9wZW4oY2hhciBjb25zdCAqZGV2bmFtZSkKK3sKKwlzdHJ1 Y3Qgc29ja2FkZHJfaGNpCWhhOworCWJkYWRkcl90CQliYTsKKwlpbnQJCQlzOworCisJaWYgKGRl dm5hbWUgPT0gTlVMTCkgeworCQllcnJubyA9IEVJTlZBTDsKKwkJcmV0dXJuICgtMSk7CisJfQor CisJbWVtc2V0KCZoYSwgMCwgc2l6ZW9mKGhhKSk7CisJaGEuaGNpX2xlbiA9IHNpemVvZihoYSk7 CisJaGEuaGNpX2ZhbWlseSA9IEFGX0JMVUVUT09USDsKKworCWlmIChidF9hdG9uKGRldm5hbWUs ICZiYSkpIHsKKwkJaWYgKCFidF9kZXZuYW1lKGhhLmhjaV9ub2RlLCAmYmEpKQorCQkJcmV0dXJu ICgtMSk7CisJfSBlbHNlIGlmIChidF9kZXYybm9kZShkZXZuYW1lLCBoYS5oY2lfbm9kZSwKKwkJ CQkJc2l6ZW9mKGhhLmhjaV9ub2RlKSkgPT0gTlVMTCkgeworCQllcnJubyA9IEVOWElPOworCQly ZXR1cm4gKC0xKTsKKwl9CisKKwlzID0gc29ja2V0KFBGX0JMVUVUT09USCwgU09DS19SQVcsIEJM VUVUT09USF9QUk9UT19IQ0kpOworCWlmIChzIDwgMCkKKwkJcmV0dXJuICgtMSk7CisKKwlpZiAo YmluZChzLCAoc3RydWN0IHNvY2thZGRyICopICZoYSwgc2l6ZW9mKGhhKSkgPCAwIHx8CisJICAg IGNvbm5lY3QocywgKHN0cnVjdCBzb2NrYWRkciAqKSAmaGEsIHNpemVvZihoYSkpIDwgMCkgewor CQljbG9zZShzKTsKKwkJcmV0dXJuICgtMSk7CisJfQorCisJcmV0dXJuIChzKTsKK30KKworaW50 CitidF9kZXZjbG9zZShpbnQgcykKK3sKKwlyZXR1cm4gKGNsb3NlKHMpKTsKK30KKworaW50Citi dF9kZXZzZW5kKGludCBzLCB1aW50MTZfdCBvZ2YsIHVpbnQxNl90IG9jZiwgaW50IHBsZW4sIHZv aWQgKnBhcmFtKQoreworCW5nX2hjaV9jbWRfcGt0X3QJaDsKKwlzdHJ1Y3QgaW92ZWMJCWl2WzJd OworCWludAkJCWl2bjsKKworCWlmIChwbGVuIDwgMCB8fCAocGxlbiA+IDAgJiYgcGFyYW0gPT0g TlVMTCkpIHsgCisJCWVycm5vID0gRUlOVkFMOworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwlpdlsw XS5pb3ZfYmFzZSA9ICZoOworCWl2WzBdLmlvdl9sZW4gPSBzaXplb2YoaCk7CisJaXZuID0gMTsK KworCWgudHlwZSA9IE5HX0hDSV9DTURfUEtUOworCWgub3Bjb2RlID0gaHRvbGUxNihOR19IQ0lf T1BDT0RFKG9nZiwgb2NmKSk7CisJaWYgKHBsZW4gPiAwKSB7CisJCWgubGVuZ3RoID0gcGxlbjsK KworCQlpdlsxXS5pb3ZfYmFzZSA9IHBhcmFtOworCQlpdlsxXS5pb3ZfbGVuID0gcGxlbjsKKwkJ aXZuID0gMjsKKwl9IGVsc2UKKwkJaC5sZW5ndGggPSAwOworCisJd2hpbGUgKHdyaXRldihzLCBp diwgaXZuKSA8IDApIHsKKwkJaWYgKGVycm5vID09IEVBR0FJTiB8fCBlcnJubyA9PSBFSU5UUikK KwkJCWNvbnRpbnVlOworCisJCXJldHVybiAoLTEpOworCX0KKworCXJldHVybiAoMCk7Cit9CisK K2ludAorYnRfZGV2cmVjdihpbnQgcywgdWludDhfdCAqYnVmLCBpbnQgc2l6ZSwgdGltZV90IHRv KQoreworCWZkX3NldAkJcmZkOworCXN0cnVjdCB0aW1ldmFsCXR2OworCWludAkJbjsKKworCWlm IChidWYgPT0gTlVMTCB8fCBzaXplIDw9IDAgfHwgdG8gPCAwKSB7CisJCWVycm5vID0gRUlOVkFM OworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwlGRF9aRVJPKCZyZmQpOworCUZEX1NFVChzLCAmcmZk KTsKKworCXR2LnR2X3NlYyA9IHRvOworCXR2LnR2X3VzZWMgPSAwOworCisJd2hpbGUgKChuID0g c2VsZWN0KHMgKyAxLCAmcmZkLCBOVUxMLCBOVUxMLCAmdHYpKSA8IDApIHsKKwkJaWYgKGVycm5v ID09IEVBR0FJTiB8fCBlcnJubyA9PSBFSU5UUikKKwkJCWNvbnRpbnVlOworCisJCXJldHVybiAo LTEpOworCX0KKworCWlmIChuID09IDApIHsKKwkJZXJybm8gPSBFVElNRURPVVQ7CisJCXJldHVy biAoLTEpOworCX0KKworCWFzc2VydChGRF9JU1NFVChzLCAmcmZkKSk7CisKKwl3aGlsZSAoKG4g PSByZWFkKHMsIGJ1Ziwgc2l6ZSkpIDwgMCkgeworCQlpZiAoZXJybm8gPT0gRUFHQUlOIHx8IGVy cm5vID09IEVJTlRSKQorCQkJY29udGludWU7CisKKwkJcmV0dXJuICgtMSk7CisJfQorCisJcmV0 dXJuIChuKTsKK30KKworaW50CitidF9kZXZyZXEoaW50IHMsIHN0cnVjdCBidF9kZXZyZXEgKnIs IHRpbWVfdCB0bykKK3sKKwl1aW50OF90CQkJCWJ1ZlszMjBdOyAvKiBtb3JlIHRoYW4gZW5vdWdo ICovCisJbmdfaGNpX2V2ZW50X3BrdF90CQkqZSA9IChuZ19oY2lfZXZlbnRfcGt0X3QgKikgYnVm OworCW5nX2hjaV9jb21tYW5kX2NvbXBsX2VwCQkqY2MgPSAobmdfaGNpX2NvbW1hbmRfY29tcGxf ZXAgKikoZSsxKTsKKwluZ19oY2lfY29tbWFuZF9zdGF0dXNfZXAJKmNzID0gKG5nX2hjaV9jb21t YW5kX3N0YXR1c19lcCopKGUrMSk7CisJdWludDE2X3QJCQlvcGNvZGU7CisJdGltZV90CQkJCXRf ZW5kOworCWludAkJCQluOworCisJaWYgKHMgPCAwIHx8IHIgPT0gTlVMTCB8fCB0byA8IDApIHsK KwkJZXJybm8gPSBFSU5WQUw7CisJCXJldHVybiAoLTEpOworCX0KKworCWlmIChyLT5ybGVuIDwg MCB8fCAoci0+cmxlbiA+IDAgJiYgci0+cnBhcmFtID09IE5VTEwpKSB7CisJCWVycm5vID0gRUlO VkFMOworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwluID0gYnRfZGV2c2VuZChzLCByLT5vZ2YsIHIt Pm9jZiwgci0+Y2xlbiwgci0+Y3BhcmFtKTsKKwlpZiAobiA8IDApCisJCXJldHVybiAoLTEpOwor CisJb3Bjb2RlID0gaHRvbGUxNihOR19IQ0lfT1BDT0RFKHItPm9nZiwgci0+b2NmKSk7CisKKwl0 X2VuZCA9IHRpbWUoTlVMTCkgKyB0bzsKKworCWRvIHsKKwkJdG8gPSB0X2VuZCAtIHRpbWUoTlVM TCk7CisJCWlmICh0byA8IDApCisJCQl0byA9IDA7CisKKwkJbiA9IGJ0X2RldnJlY3YocywgYnVm LCBzaXplb2YoYnVmKSwgdG8pOworCQlpZiAobiA8IDApCisJCQlyZXR1cm4gKC0xKTsKKworCQlp ZiAobiA8IHNpemVvZigqZSkpIHsKKwkJCWVycm5vID0gRU1TR1NJWkU7CisJCQlyZXR1cm4gKC0x KTsKKwkJfQorCisJCWlmIChlLT50eXBlICE9IE5HX0hDSV9FVkVOVF9QS1QpIHsKKwkJCWVycm5v ID0gRUlPOworCQkJcmV0dXJuICgtMSk7CisJCX0KKworCQluIC09IHNpemVvZigqZSk7CisKKwkJ c3dpdGNoIChlLT5ldmVudCkgeworCQljYXNlIE5HX0hDSV9FVkVOVF9DT01NQU5EX0NPTVBMOgor CQkJaWYgKGNjLT5vcGNvZGUgPT0gb3Bjb2RlKSB7CisJCQkJbiAtPSBzaXplb2YoKmNjKTsKKwor CQkJCWlmIChyLT5ybGVuID49IG4pIHsKKwkJCQkJci0+cmxlbiA9IG47CisJCQkJCW1lbWNweShy LT5ycGFyYW0sIGNjICsgMSwgci0+cmxlbik7CisJCQkJfQorCisJCQkJcmV0dXJuICgwKTsKKwkJ CX0KKwkJCWJyZWFrOworCisJCWNhc2UgTkdfSENJX0VWRU5UX0NPTU1BTkRfU1RBVFVTOgorCQkJ aWYgKGNzLT5vcGNvZGUgPT0gb3Bjb2RlKSB7CisJCQkJaWYgKHItPmV2ZW50ICE9IE5HX0hDSV9F VkVOVF9DT01NQU5EX1NUQVRVUykgeworCQkJCQlpZiAoY3MtPnN0YXR1cyAhPSAwKSB7CisJCQkJ CQllcnJubyA9IEVJTzsKKwkJCQkJCXJldHVybiAoLTEpOworCQkJCQl9CisJCQkJfSBlbHNlIHsK KwkJCQkJaWYgKHItPnJsZW4gPj0gbikgeworCQkJCQkJci0+cmxlbiA9IG47CisJCQkJCQltZW1j cHkoci0+cnBhcmFtLCBjcywgci0+cmxlbik7CisJCQkJCX0KKworCQkJCQlyZXR1cm4gKDApOwor CQkJCX0KKwkJCX0KKwkJCWJyZWFrOworCisJCWRlZmF1bHQ6CisJCQlpZiAoZS0+ZXZlbnQgPT0g ci0+ZXZlbnQpIHsKKwkJCQlpZiAoci0+cmxlbiA+PSBuKSB7CisJCQkJCXItPnJsZW4gPSBuOwor CQkJCQltZW1jcHkoci0+cnBhcmFtLCBlICsgMSwgci0+cmxlbik7CisJCQkJfQorCisJCQkJcmV0 dXJuICgwKTsKKwkJCX0KKwkJCWJyZWFrOworCQl9CisJfSB3aGlsZSAodG8gPiAwKTsKKworCWVy cm5vID0gRVRJTUVET1VUOworCisJcmV0dXJuICgtMSk7Cit9CisKK2ludAorYnRfZGV2ZmlsdGVy KGludCBzLCBzdHJ1Y3QgYnRfZGV2ZmlsdGVyIGNvbnN0ICpuZXcsIHN0cnVjdCBidF9kZXZmaWx0 ZXIgKm9sZCkKK3sKKwlzdHJ1Y3QgbmdfYnRzb2NrZXRfaGNpX3Jhd19maWx0ZXIJZjsKKwlzb2Nr bGVuX3QJCQkJbGVuOworCWludAkJCQkJYml0OworCisJaWYgKG5ldyA9PSBOVUxMICYmIG9sZCA9 PSBOVUxMKSB7CisJCWVycm5vID0gRUlOVkFMOworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwlpZiAo b2xkICE9IE5VTEwpIHsKKwkJbGVuID0gc2l6ZW9mKGYpOworCQlpZiAoZ2V0c29ja29wdChzLCBT T0xfSENJX1JBVywgU09fSENJX1JBV19GSUxURVIsICZmLCAmbGVuKSA8IDApCisJCQlyZXR1cm4g KC0xKTsKKworCQltZW1zZXQob2xkLCAwLCBzaXplb2YoKm9sZCkpOworCisJCWZvciAoYml0ID0g MDsgYml0IDwgTkdfSENJX0VWRU5UX1BLVDsgYml0ICsrKQorCQkJaWYgKGJpdF90ZXN0KGYucGFj a2V0X21hc2ssIGJpdCkpCisJCQkJb2xkLT5wYWNrZXRfbWFzayB8PSAoMSA8PCBiaXQpOworCisJ CWZvciAoYml0ID0gMDsgYml0IDwgTkdfSENJX0VWRU5UX01BU0tfU0laRSAqIDg7IGJpdCArKykK KwkJCWlmIChiaXRfdGVzdChmLmV2ZW50X21hc2ssIGJpdCkpCisJCQkJb2xkLT5ldmVudF9tYXNr IHw9ICgxIDw8IGJpdCk7CisJfQorCisJaWYgKG5ldyAhPSBOVUxMKSB7CisJCW1lbXNldCgmZiwg MCwgc2l6ZW9mKGYpKTsKKworCQlmb3IgKGJpdCA9IDA7IGJpdCA8IE5HX0hDSV9FVkVOVF9QS1Q7 IGJpdCArKykKKwkJCWlmIChuZXctPnBhY2tldF9tYXNrICYgKDEgPDwgYml0KSkKKwkJCQliaXRf c2V0KGYucGFja2V0X21hc2ssIGJpdCk7CisKKwkJZm9yIChiaXQgPSAwOyBiaXQgPCAoTkdfSENJ X0VWRU5UX01BU0tfU0laRSAqIDgpOyBiaXQgKyspCisJCQlpZiAobmV3LT5ldmVudF9tYXNrICYg KDEgPDwgYml0KSkKKwkJCQliaXRfc2V0KGYuZXZlbnRfbWFzaywgYml0KTsKKworCQlsZW4gPSBz aXplb2YoZik7CisJCWlmIChzZXRzb2Nrb3B0KHMsIFNPTF9IQ0lfUkFXLCBTT19IQ0lfUkFXX0ZJ TFRFUiwgJmYsIGxlbikgPCAwKQorCQkJcmV0dXJuICgtMSk7CisJfQorCisJcmV0dXJuICgwKTsK K30KKworaW50CitidF9kZXZpbnF1aXJ5KGNoYXIgY29uc3QgKmRldm5hbWUsIGludCBsZW5ndGgs IGludCBudW1fcnNwLAorCQl1aW50OF90IGNvbnN0ICpsYXAsIHN0cnVjdCBidF9kZXZpbnF1aXJ5 ICoqaWkpCit7CisJdWludDhfdAkJCQlidWZbMzIwXTsKKwljaGFyCQkJCV9kZXZuYW1lW0hDSV9E RVZOQU1FX1NJWkVdOworCXN0cnVjdCBidF9kZXZmaWx0ZXIJCWY7CisJbmdfaGNpX2lucXVpcnlf Y3AJCSpjcCA9IChuZ19oY2lfaW5xdWlyeV9jcCAqKSBidWY7CisJbmdfaGNpX2V2ZW50X3BrdF90 CQkqZSA9IChuZ19oY2lfZXZlbnRfcGt0X3QgKikgYnVmOworCW5nX2hjaV9pbnF1aXJ5X3Jlc3Vs dF9lcAkqZXAgPSAobmdfaGNpX2lucXVpcnlfcmVzdWx0X2VwICopKGUrMSk7CisJbmdfaGNpX2lu cXVpcnlfcmVzcG9uc2UJCSppcjsKKwlzdHJ1Y3QgYnRfZGV2aW5xdWlyeQkJKmk7CisJaW50CQkJ CXMsIG47CisJdGltZV90CQkJCXRvOworCisJaWYgKGlpID09IE5VTEwpIHsKKwkJZXJybm8gPSBF SU5WQUw7CisJCXJldHVybiAoLTEpOworCX0KKworCWlmIChkZXZuYW1lID09IE5VTEwpIHsKKwkJ bWVtc2V0KF9kZXZuYW1lLCAwLCBzaXplb2YoX2Rldm5hbWUpKTsKKwkJZGV2bmFtZSA9IF9kZXZu YW1lOworCisJCW4gPSBidF9kZXZlbnVtKGJ0X2RldmFueV9jYiwgX2Rldm5hbWUpOworCQlpZiAo biA8PSAwKSB7CisJCQlpZiAobiA9PSAwKQorCQkJCSppaSA9IE5VTEw7CisKKwkJCXJldHVybiAo bik7CisJCX0KKwl9CisKKwlzID0gYnRfZGV2b3BlbihkZXZuYW1lKTsKKwlpZiAocyA8IDApCisJ CXJldHVybiAoLTEpOworCisJaWYgKGJ0X2RldmZpbHRlcihzLCBOVUxMLCAmZikgPCAwKSB7CisJ CWJ0X2RldmNsb3NlKHMpOworCQlyZXR1cm4gKC0xKTsKKwl9CisKKwlmLmV2ZW50X21hc2sgfD0g KDEgPDwgKE5HX0hDSV9FVkVOVF9JTlFVSVJZX0NPTVBMIC0gMSkpOworCWYuZXZlbnRfbWFzayB8 PSAoMSA8PCAoTkdfSENJX0VWRU5UX0lOUVVJUllfUkVTVUxUIC0gMSkpOworCisJaWYgKGJ0X2Rl dmZpbHRlcihzLCAmZiwgTlVMTCkgPCAwKSB7CisJCWJ0X2RldmNsb3NlKHMpOworCQlyZXR1cm4g KC0xKTsKKwl9CisKKwlpZiAobGFwID09IE5VTEwpIHsKKwkJY3AtPmxhcFswXSA9IDB4MzM7CisJ CWNwLT5sYXBbMV0gPSAweDhiOworCQljcC0+bGFwWzJdID0gMHg5ZTsKKwl9IGVsc2UgeworCQlj cC0+bGFwWzBdID0gbGFwWzBdOworCQljcC0+bGFwWzFdID0gbGFwWzFdOworCQljcC0+bGFwWzJd ID0gbGFwWzJdOworCX0KKworCWlmIChsZW5ndGggPD0gMCB8fCBsZW5ndGggPiAyNTUpCisJCWxl bmd0aCA9IDQ7CS8qIDUuMTIgc2Vjb25kcyAqLworCWNwLT5pbnF1aXJ5X2xlbmd0aCA9ICh1aW50 OF90KSBsZW5ndGg7CisKKwl0byA9ICh0aW1lX3QpKChkb3VibGUpIGxlbmd0aCAqIDEuMjgpICsg MTsKKworCWlmIChudW1fcnNwIDw9IDAgfHwgbnVtX3JzcCA+IDI1NSkKKwkJbnVtX3JzcCA9IDg7 CisJY3AtPm51bV9yZXNwb25zZXMgPSAodWludDhfdCkgbnVtX3JzcDsKKworCWkgPSAqaWkgPSBj YWxsb2MobnVtX3JzcCwgc2l6ZW9mKHN0cnVjdCBidF9kZXZpbnF1aXJ5KSk7CisJaWYgKGkgPT0g TlVMTCkgeworCQlidF9kZXZjbG9zZShzKTsKKwkJZXJybm8gPSBFTk9NRU07CisJCXJldHVybiAo LTEpOworCX0KKworCWlmIChidF9kZXZzZW5kKHMsIE5HX0hDSV9PR0ZfTElOS19DT05UUk9MLCBO R19IQ0lfT0NGX0lOUVVJUlksCisJCQlzaXplb2YoKmNwKSwgY3ApIDwgMCkgeworCQlmcmVlKGkp OworCQlidF9kZXZjbG9zZShzKTsKKwkJcmV0dXJuICgtMSk7CisJfQorCit3YWl0X2Zvcl9tb3Jl OgorCisJbiA9IGJ0X2RldnJlY3YocywgYnVmLCBzaXplb2YoYnVmKSwgdG8pOworCWlmIChuIDwg MCkgeworCQlmcmVlKGkpOworCQlidF9kZXZjbG9zZShzKTsKKwkJcmV0dXJuICgtMSk7CisJfQor CisJaWYgKG4gPCBzaXplb2YobmdfaGNpX2V2ZW50X3BrdF90KSkgeworCQlmcmVlKGkpOworCQli dF9kZXZjbG9zZShzKTsKKwkJZXJybm8gPSBFSU87CisJCXJldHVybiAoLTEpOworCX0KKworCXN3 aXRjaCAoZS0+ZXZlbnQpIHsKKwljYXNlIE5HX0hDSV9FVkVOVF9JTlFVSVJZX0NPTVBMOgorCQli cmVhazsKKworCWNhc2UgTkdfSENJX0VWRU5UX0lOUVVJUllfUkVTVUxUOgorCQlpciA9IChuZ19o Y2lfaW5xdWlyeV9yZXNwb25zZSAqKShlcCArIDEpOworCisjdW5kZWYJTUlOCisjZGVmaW5lCU1J TihhLCBiKQkoKChhKSA8IChiKSk/IChhKSA6IChiKSkKKworCQlmb3IgKG4gPSAwOyBuIDwgTUlO KGVwLT5udW1fcmVzcG9uc2VzLCBudW1fcnNwKTsgbiArKykgeworCQkJYmRhZGRyX2NvcHkoJmkt PmJkYWRkciwgJmlyLT5iZGFkZHIpOworCQkJaS0+cHNjYW5fcmVwX21vZGUgPSBpci0+cGFnZV9z Y2FuX3JlcF9tb2RlOworCQkJaS0+cHNjYW5fcGVyaW9kX21vZGUgPSBpci0+cGFnZV9zY2FuX3Bl cmlvZF9tb2RlOworCQkJaS0+cHNjYW5fbW9kZSA9IGlyLT5wYWdlX3NjYW5fbW9kZTsKKwkJCW1l bWNweShpLT5kZXZfY2xhc3MsIGlyLT51Y2xhc3MsIHNpemVvZihpLT5kZXZfY2xhc3MpKTsKKwkJ CWktPmNsb2NrX29mZnNldCA9IGxlMTZ0b2goaXItPmNsb2NrX29mZnNldCk7CisKKwkJCWlyICsr OworCQkJaSArKzsKKwkJCW51bV9yc3AgLS07CisJCX0KKwkJLyogRkFMTFRIUk9VR0ggKi8KKwor CWRlZmF1bHQ6CisJCWdvdG8gd2FpdF9mb3JfbW9yZTsKKwkJLyogTk9UIFJFQUNIRUQgKi8KKwl9 CisKKwlidF9kZXZjbG9zZShzKTsKKwkJCisJcmV0dXJuIChpIC0gKmlpKTsKK30KKworaW50CiBi dF9kZXZpbmZvKHN0cnVjdCBidF9kZXZpbmZvICpkaSkKIHsKIAl1bmlvbiB7CkBAIC01Myw2ICs0 NTksNyBAQAogCQlzdHJ1Y3QgbmdfYnRzb2NrZXRfaGNpX3Jhd19ub2RlX2RlYnVnCQlyODsKIAl9 CQkJCQkJcnA7CiAJc3RydWN0IHNvY2thZGRyX2hjaQkJCQloYTsKKwlzb2NrbGVuX3QJCQkJCWhh bGVuOwogCWludAkJCQkJCXMsIHJ2YWw7CiAKIAlpZiAoZGkgPT0gTlVMTCkgewpAQCAtNjAsMjcg KzQ2NywxNCBAQAogCQlyZXR1cm4gKC0xKTsKIAl9CiAKLQltZW1zZXQoJmhhLCAwLCBzaXplb2Yo aGEpKTsKLQloYS5oY2lfbGVuID0gc2l6ZW9mKGhhKTsKLQloYS5oY2lfZmFtaWx5ID0gQUZfQkxV RVRPT1RIOwotCi0JaWYgKGJ0X2F0b24oZGktPmRldm5hbWUsICZycC5yMS5iZGFkZHIpKSB7Ci0J CWlmICghYnRfZGV2bmFtZShoYS5oY2lfbm9kZSwgJnJwLnIxLmJkYWRkcikpCi0JCQlyZXR1cm4g KC0xKTsKLQl9IGVsc2UgaWYgKGJ0X2RldjJub2RlKGRpLT5kZXZuYW1lLCBoYS5oY2lfbm9kZSwK LQkJCQkJc2l6ZW9mKGhhLmhjaV9ub2RlKSkgPT0gTlVMTCkgewotCQllcnJubyA9IEVOWElPOwot CQlyZXR1cm4gKC0xKTsKLQl9Ci0KLQlzID0gc29ja2V0KFBGX0JMVUVUT09USCwgU09DS19SQVcs IEJMVUVUT09USF9QUk9UT19IQ0kpOworCXMgPSBidF9kZXZvcGVuKGRpLT5kZXZuYW1lKTsKIAlp ZiAocyA8IDApCiAJCXJldHVybiAoLTEpOwogCiAJcnZhbCA9IC0xOwogCi0JaWYgKGJpbmQocywg KHN0cnVjdCBzb2NrYWRkciAqKSAmaGEsIHNpemVvZihoYSkpIDwgMCB8fAotCSAgICBjb25uZWN0 KHMsIChzdHJ1Y3Qgc29ja2FkZHIgKikgJmhhLCBzaXplb2YoaGEpKSA8IDApCisJaGFsZW4gPSBz aXplb2YoaGEpOworCWlmIChnZXRzb2NrbmFtZShzLCAoc3RydWN0IHNvY2thZGRyICopICZoYSwg JmhhbGVuKSA8IDApCiAJCWdvdG8gYmFkOwogCXN0cmxjcHkoZGktPmRldm5hbWUsIGhhLmhjaV9u b2RlLCBzaXplb2YoZGktPmRldm5hbWUpKTsKIApAQCAtMTM4LDcgKzUzMiw3IEBACiAKIAlydmFs ID0gMDsKIGJhZDoKLQljbG9zZShzKTsKKwlidF9kZXZjbG9zZShzKTsKIAogCXJldHVybiAocnZh bCk7CiB9CkBAIC0yMDUsNiArNTk5LDEzIEBACiAJcmV0dXJuIChjb3VudCk7CiB9CiAKK3N0YXRp YyBpbnQKK2J0X2RldmFueV9jYihpbnQgcywgc3RydWN0IGJ0X2RldmluZm8gY29uc3QgKmRpLCB2 b2lkICp4ZGV2bmFtZSkKK3sKKwlzdHJsY3B5KChjaGFyICopIHhkZXZuYW1lLCBkaS0+ZGV2bmFt ZSwgSENJX0RFVk5BTUVfU0laRSk7CisJcmV0dXJuICgxKTsKK30KKwogc3RhdGljIGNoYXIgKgog YnRfZGV2Mm5vZGUoY2hhciBjb25zdCAqZGV2bmFtZSwgY2hhciAqbm9kZW5hbWUsIGludCBubmxl bikKIHsKSW5kZXg6IGJsdWV0b290aC4zCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGJsdWV0b290aC4zCShyZXZp c2lvbiAxOTA4NzApCisrKyBibHVldG9vdGguMwkod29ya2luZyBjb3B5KQpAQCAtMjUsNyArMjUs NyBAQAogLlwiICRJZDogYmx1ZXRvb3RoLjMsdiAxLjUgMjAwMy8wNS8yMCAyMzowNDozMCBtYXgg RXhwICQKIC5cIiAkRnJlZUJTRCQKIC5cIgotLkRkIEZlYnJ1YXJ5IDEzLCAyMDA5CisuRGQgQXBy aWwgOSwgMjAwOQogLkR0IEJMVUVUT09USCAzCiAuT3MKIC5TaCBOQU1FCkBAIC00MSw2ICs0MSwx NyBAQAogLk5tIGJ0X2VuZHByb3RvZW50ICwKIC5ObSBidF9hdG9uICwKIC5ObSBidF9udG9hICwK Ky5ObSBidF9kZXZhZGRyICwKKy5ObSBidF9kZXZuYW1lICwKKy5ObSBidF9kZXZpbmZvICwKKy5O bSBidF9kZXZlbnVtICwKKy5ObSBidF9kZXZvcGVuICwKKy5ObSBidF9kZXZjbG9zZSAsCisuTm0g YnRfZGV2c2VuZCAsCisuTm0gYnRfZGV2cmVjdiAsCisuTm0gYnRfZGV2cmVxICwKKy5ObSBidF9k ZXZmaWx0ZXIgLAorLk5tIGJ0X2RldmlucXVpcnkgLAogLk5tIGJkYWRkcl9zYW1lICwKIC5ObSBi ZGFkZHJfYW55ICwKIC5ObSBiZGFkZHJfY29weQpAQCAtODQsNiArOTUsMjAgQEAKIC5GdCBpbnQK IC5GbiBidF9kZXZlbnVtICJidF9kZXZlbnVtX2NiX3QgKmNiIiAidm9pZCAqYXJnIgogLkZ0IGlu dAorLkZuIGJ0X2Rldm9wZW4gImNoYXIgY29uc3QgKmRldm5hbWUiCisuRnQgaW50CisuRm4gYnRf ZGV2Y2xvc2UgImludCBzIgorLkZ0IGludAorLkZuIGJ0X2RldnNlbmQgImludCBzIiAidWludDE2 X3Qgb2dmIiAidWludDE2X3Qgb2NmIiAiaW50IHBsZW4iICJ2b2lkICpwYXJhbSIKKy5GdCBpbnQK Ky5GbiBidF9kZXZyZWN2ICJpbnQgcyIgInVpbnQ4X3QgKmJ1ZiIgImludCBzaXplIiAidGltZV90 IHRvIgorLkZ0IGludAorLkZuIGJ0X2RldnJlcSAiaW50IHMiICJzdHJ1Y3QgYnRfZGV2cmVxICpy IiAidGltZV90IHRvIgorLkZ0IGludAorLkZuIGJ0X2RldmZpbHRlciAiaW50IHMiICJzdHJ1Y3Qg YnRfZGV2ZmlsdGVyIGNvbnN0ICpuZXciICJzdHJ1Y3QgYnRfZGV2ZmlsdGVyICpvbGQiCisuRnQg aW50CisuRm4gYnRfZGV2aW5xdWlyeSAiY2hhciBjb25zdCAqZGV2bmFtZSIgImludCBsZW5ndGgi ICJpbnQgbnVtX3JzcCIgInVpbnQ4X3QgY29uc3QgKmxhcCIgInN0cnVjdCBidF9kZXZpbnF1aXJ5 ICoqaWkiCisuRnQgaW50CiAuRm4gYmRhZGRyX3NhbWUgImNvbnN0IGJkYWRkcl90ICphIiAiY29u c3QgYmRhZGRyX3QgKmIiCiAuRnQgaW50CiAuRm4gYmRhZGRyX2FueSAiY29uc3QgYmRhZGRyX3Qg KmEiCkBAIC0zMTEsNiArMzM2LDIxOSBAQAogb3IgLTEgaWYgYW4gZXJyb3Igb2NjdXJyZWQuCiAu UHAKIFRoZQorLkZuIGJ0X2Rldm9wZW4KK2Z1bmN0aW9uIG9wZW5zIEJsdWV0b290aCBkZXZpY2Ug d2l0aCB0aGUgZ2l2ZW4KKy5GYSBkZXZuYW1lCithbmQgcmV0dXJucyBjb25uZWN0ZWQgYW5kIGJv dW5kCisuRHYgSENJCitzb2NrZXQuCitUaGUgZnVuY3Rpb24gcmV0dXJucyAtMSBpZiBhbiBlcnJv ciBoYXMgb2NjdXJyZWQuCisuUHAKK1RoZQorLkZuIGJ0X2RldmNsb3NlCitjbG9zZXMgcGFzc2Vk CisuRHYgSENJCitzb2NrZXQKKy5GYSBzICwKK3ByZXZpb3VzbHkgb2J0YWluZWQgd2l0aAorLlhy IGJ0X2Rldm9wZW4gMyAuCisuUHAKK1RoZQorLkZuIGJ0X2RldnNlbmQKK2Z1bmN0aW9uIHNlbmRz IEJsdWV0b290aAorLkR2IEhDSQorY29tbWFuZCB3aXRoIHRoZSBPcENvZGUgR3JvdXAgRmllbGQK Ky5GYSBvZ2YKK2FuZAorT3BDb2RlIENvbW1hbmQgRmllbGQKKy5GYSBvY2YKK3RvIHRoZSBwcm92 aWRlZCBzb2NrZXQKKy5GYSBzICwKK3ByZXZpb3VzbHkgb2J0YWluZWQgd2l0aAorLlhyIGJ0X2Rl dm9wZW4gMyAuCitUaGUKKy5GYSBwbGVuCithbmQKKy5GYSBwYXJhbQorcGFyYW1ldGVycyBzcGVj aWZ5IGNvbW1hbmQgcGFyYW1ldGVycy4KK1RoZSBmdW5jdGlvbiByZXR1cm5zIDAgb24gc3VjY2Vz cywKK29yIC0xIGlmIGFuIGVycm9yIG9jY3VycmVkLgorLlBwCitUaGUKKy5GbiBidF9kZXZyZWN2 CitmdW5jdGlvbiByZWNlaXZlcyBvbmUgQmx1ZXRvb3RoCisuRHYgSENJCitldmVudCBwYWNrZXQg ZnJvbSB0aGUgc29ja2V0CisuRmEgcyAsCitwcmV2aW91c2x5IG9idGFpbmVkIHdpdGgKKy5YciBi dF9kZXZvcGVuIDMgLgorVGhlIGV2ZW50IHBhY2tldCBpcyBwbGFjZWQgaW50byB0aGUgcHJvdmlk ZWQgYnVmZmVyCisuRmEgYnVmCitvZiBzaXplCisuRmEgc2l6ZSAuCitUaGUKKy5GYSB0bworcGFy YW1ldGVyIHNwZWNpZmllcyByZWNlaXZlIHRpbWVvdXQgaW4gc2Vjb25kcy4KK1RoZSBmdW5jdGlv biByZXR1cm5zIHRvdGFsIG51bWJlciBvZiBieXRlcyByZWNldmllZCwKK29yIC0xIGlmIGFuIGVy cm9yIG9jY3VycmVkLgorLlBwCitUaGUKKy5GbiBidF9kZXZyZXEKK2Z1bmN0aW9uIG1ha2VzIEJs dWV0b290aAorLkR2IEhDSQorcmVxdWVzdCB0byB0aGUgc29ja2V0CisuRmEgcyAsCitwcmV2aW91 c2x5IG9idGFpbmVkIHdpdGgKKy5YciBidF9kZXZvcGVuIDMgLgorVGhlIGZ1bmN0aW9uIHdpbGwg c2VuZCB0aGUgc3BlY2lmaWVkIGNvbW1hbmQgYW5kIHdpbGwgd2FpdCBmb3IgdGhlIHNwZWNpZmll ZAorZXZlbnQsCitvciB0aW1lb3V0CisuRmEgdG8KK3NlY29uZHMgdG8gb2NjdXIuCitUaGUKKy5W dCBidF9kZXZyZXEKK3N0cnVjdHVyZSBpcyBkZWZpbmVkIGFzIGZvbGxvd3MKKy5CZCAtbGl0ZXJh bCAtb2Zmc2V0IGluZGVudAorc3RydWN0IGJ0X2RldnJlcQoreworICAgICAgICB1aW50MTZfdCAg ICAgICAgb2dmOworICAgICAgICB1aW50MTZfdCAgICAgICAgb2NmOworICAgICAgICBpbnQgICAg ICAgICAgICAgZXZlbnQ7CisgICAgICAgIHZvaWQgICAgICAgICAgICAqY3BhcmFtOworICAgICAg ICBpbnQgICAgICAgICAgICAgY2xlbjsKKyAgICAgICAgdm9pZCAgICAgICAgICAgICpycGFyYW07 CisgICAgICAgIGludCAgICAgICAgICAgICBybGVuOworfTsKKy5FZAorLlBwCitUaGUKKy5GYSBv Z2YKK2FuZAorLkZhIG9jZgorZmllbGRzIHNwZWNpZnkgT3BDb2RlIEdyb3VwIGFuZCBDb21tYW5k IEZpZWxkIHJlc3BlY3RpdmVseS4KK1RoZQorLkZhIGNwYXJhbQorYW5kCisuRmEgY2xlbgorZmll bGRzIHNwZWNpZnkgY29tbWFuZCBwYXJhbWV0ZXJzIGRhdGEgYW5kIGNvbW1hbmQgcGFyYW1ldGVy cyBkYXRhIHNpemUKK3Jlc3BlY3RpdmVseS4KK1RoZQorLkZhIGV2ZW50CitmaWVsZCBzcGVjaWZp ZXMgd2hpY2ggQmx1ZXRvb3RoCisuRHYgSENJCitldmVudCBJRCB0aGUgZnVuY3Rpb24gc2hvdWxk IHdhaXQgZm9yLgorVGhlCisuRmEgcnBhcmFtCithbmQKKy5GYSBybGVuCitwYXJhbWV0ZXJzIHNw ZWNpZnkgYnVmZmVyIGFuZCBidWZmZXIgc2l6ZSByZXNwZWN0aXZlbHkgd2hlcmUgcmV0dXJuCitw YXJhbWV0ZXJzIHNob3VsZCBiZSBwbGFjZWQuCitUaGUgZnVuY3Rpb24gcmV0dXJucyAwIG9uIHN1 Y2Nlc3MsIG9yIC0xIGlmIGFuIGVycm9yIG9jY3VycmVkLgorLlBwCitUaGUKKy5GbiBidF9kZXZm aWx0ZXIKK2NvbnRyb2xzIHRoZSBsb2NhbAorLkR2IEhDSQorZmlsdGVyIGFzc29jaWF0ZWQgd2l0 aCB0aGUgc29ja2V0CisuRmEgcyAsCitwcmV2aW91c2x5IG9idGFpbmVkIHdpdGgKKy5YciBidF9k ZXZvcGVuIDMgLgorRmlsdGVyaW5nIGNhbiBiZSBkb25lIG9uIHBhY2tldCB0eXBlcywgaS5lLgor LkR2IEFDTCAsCisuRHYgU0NPIG9yCisuRHYgSENJCitldmVudCBwYWNrZXRzLCBhbmQsIGluIGFk ZGl0aW9uLCBvbgorLkR2IEhDSQorZXZlbnQgSURzLgorQmVmb3JlIGFwcGx5aW5nCisuRmEgbmV3 CitmaWx0ZXIgKGlmIHByb3ZpZGVkKSB0aGUgZnVuY3Rpb24gd2lsbCB0cnkgdG8gb2J0YWluIGN1 cnJlbnQgZmlsdGVyCitmcm9tIHRoZSBzb2NrZXQKKy5GYSBzCithbmQgcGxhY2UgaXQgaW50byB0 aGUKKy5GYSBvbGQKK3BhcmFtZXRlciAoaWYgcHJvdmlkZWQpLgorVGhlCisuVnQgYnRfZGV2Zmls dGVyCitzdHJ1Y3R1cmUgaXMgZGVmaW5lZCBhcyBmb2xsb3dzCisuQmQgLWxpdGVyYWwgLW9mZnNl dCBpbmRlbnQKK3N0cnVjdCBidF9kZXZmaWx0ZXIgeworICAgICAgICB1aW50NjRfdCAgICAgICAg ZXZlbnRfbWFzazsKKyAgICAgICAgdWludDhfdCAgICAgICAgIHBhY2tldF9tYXNrOworfTsKKy5F ZAorLlBwCitCb3RoCisuRmEgZXZlbnRfbWFzaworYW5kCisuRmEgcGFja2V0X21hc2sKK2ZpZWxk cyBhcmUgYml0IG1hc2tzLgorSWYgYSBiaXQKKy5GYSBOCitpcyBjbGVhcmVkIGluIHRoZQorLkZh IGV2ZW50X21hc2sKK3RoZW4gdGhlIGNvcnJlc3BvbmRpbmcgQmx1ZXRvb3RoCisuRHYgSENJCitl dmVudCBJRAorLkZhIE4KK2lzIGZpbHRlcmVkIG91dC4KK0lmIGEgYml0CisuRmEgTgoraXMgY2xl YXJlZCBpbiB0aGUKKy5GYSBwYWNrZXRfbWFzawordGhlbiBhbGwgdGhlIHBhY2tldHMgd2l0aCB0 aGUgY29ycmVzcG9uZGluZyBwYWNrZXQgaW5kaWNhdG9yIGFyZSBmaWx0ZXJlZCBvdXQuCitUaGUg ZnVuY3Rpb24gcmV0dXJucyAwIG9uIHN1Y2Nlc3MsIG9yIC0xIGlmIGFuIGVycm9yIG9jY3VycmVk LgorLlBwCitUaGUKKy5GbiBidF9kZXZpbnF1aXJ5CitmdW5jdGlvbiBwZXJmb3JtcyBCbHVldG9v dGggaW5xdWlyeS4KK1RoZQorLkZhIGRldm5hbWUKK3BhcmFtZXRlciBzcGVjaWZpZXMgd2hpY2gg bG9jYWwgQmx1ZXRvb3RoIGRldmljZSBzaG91bGQgcGVyZm9ybSBhbiBpbnF1aXJ5LgorSWYgbm90 IHNlY2lmaWVkLCBpLmUuCisuRHYgTlVMTCAsCit0aGVuIGZpcnN0IGF2YWlsYWJsZSBkZXZpY2Ug d2lsbCBiZSB1c2VkLgorVGhlCisuRmEgbGVuZ3RoCitwYXJhbWV0ZXJzIHNwZWNpZmllcyB0aGUg dG90YWwgbGVuZ3RoIG9mIGFuIGlucXVpcnkgaW4gMS4yOCBzZWNvbmQgdW5pdHMuCitJZiBub3Qg c3BlY2lmaWVkLCBpLmUuIDAsIGRlZmF1bHQgdmFsdWUgd2lsbCBiZSB1c2VkLgorVGhlCisuRmEg bnVtX3JzcAorcGFyYW1ldGVyIHNwZWNpZmllcyB0aGUgbnVtYmVyIG9mIHJlc3BvbnNlcyB0aGF0 IGNhbiBiZSByZWNlaXZlZCBiZWZvcmUKK3RoZSBpbnF1aXJ5IGlzIGhhbHRlZC4KK0lmIG5vdCBz cGVjaWZpZWQsIGkuZS4gMCwgZGVmYXVsdCB2YWx1ZSB3aWxsIGJlIHVzZWQuCitUaGUKKy5GYSBs YXAKK3BhcmFtZXRlciBjb250YWlucyB0aGUgTEFQIGZyb20gd2hpY2ggdGhlIGlucXVpcnkgYWNj ZXNzIGNvZGUgd2lsbCBiZQorYmUgZGVyaXZlZCB3aGVuIHRoZSBpbnF1aXJ5IHByb2NlZHVyZSBp cyBtYWRlLgorSWYgbm90IHNwZWNpZmllZCwgaS5lLgorLkR2IE5VTEwgLAordGhlbiBHSUFDIExB UCA5ZTo4YjozMyB3aWxsIGJlIHVzZWQuCitUaGUKKy5GYSBpaQorcGFyYW1ldGVyIHNwZWNpZmll cyB3aGVyZSB0byBwbGFjZSBpbnF1aXJ5IHJlc3VsdHMuCitPbiBzdWNjZXNzLCB0aGUgZnVuY3Rp b24gd2lsbCByZXR1cm4gdG90YWwgbnVtYmVyIG9mIGlucXVpcnkgcmVzdWx0cywKK3dpbGwgYWxs b2NhdGUgYnVmZmVyIHRvIHN0b3JlIGFsbCB0aGUgaW5xdWlyeSByZXN1bHRzIGFuZAord2lsbCBy ZXR1cm4gcG9pbnRlciB0byB0aGUgYWxsb2NhdGVkIGJ1ZmZlciBpbiB0aGUKKy5GYSBpaQorcGFy YW1ldGVyLgorSXQgaXMgdXAgdG8gdGhlIGNhbGxlciBvZiB0aGUgZnVuY3Rpb24gdG8gZGlzcG9z ZSBvZiB0aGUgYnVmZmVyLgorVGhlIGZ1bmN0aW9uIHJldHVybnMgLTEgaWYgYW4gZXJyb3IgaGFz IG9jY3VycmVkLgorVGhlCisuVnQgYnRfZGV2aW5xdWlyeQorc3RydWN0dXJlIGlzIGRlZmluZWQg YXMgZm9sbG93cworLkJkIC1saXRlcmFsIC1vZmZzZXQgaW5kZW50CitzdHJ1Y3QgYnRfZGV2aW5x dWlyeSB7CisgICAgICAgIGJkYWRkcl90ICAgICAgICBiZGFkZHI7CisgICAgICAgIHVpbnQ4X3Qg ICAgICAgICBwc2Nhbl9yZXBfbW9kZTsKKyAgICAgICAgdWludDhfdCAgICAgICAgIHBzY2FuX3Bl cmlvZF9tb2RlOworICAgICAgICB1aW50OF90ICAgICAgICAgcHNjYW5fbW9kZTsKKyAgICAgICAg dWludDhfdCAgICAgICAgIGRldl9jbGFzc1szXTsKKyAgICAgICAgdWludDE2X3QgICAgICAgIGNs b2NrX29mZnNldDsKK307CisuRWQKKy5QcAorVGhlCiAuRm4gYmRhZGRyX3NhbWUgLAogLkZuIGJk YWRkcl9hbnkKIGFuZApJbmRleDogYmx1ZXRvb3RoLmgKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gYmx1ZXRvb3Ro LmgJKHJldmlzaW9uIDE5MDg3MCkKKysrIGJsdWV0b290aC5oCSh3b3JraW5nIGNvcHkpCkBAIC0z OSw2ICszOSw3IEBACiAjaW5jbHVkZSA8c3lzL2VuZGlhbi5oPgogI2luY2x1ZGUgPHN5cy9pb2N0 bC5oPgogI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KKyNpbmNsdWRlIDxzeXMvdWlvLmg+CiAjaW5j bHVkZSA8c3lzL3VuLmg+CiAjaW5jbHVkZSA8ZXJybm8uaD4KICNpbmNsdWRlIDxuZXRkYi5oPgpA QCAtNDYsNiArNDcsNyBAQAogI2luY2x1ZGUgPG5ldGdyYXBoL2JsdWV0b290aC9pbmNsdWRlL25n X2hjaS5oPgogI2luY2x1ZGUgPG5ldGdyYXBoL2JsdWV0b290aC9pbmNsdWRlL25nX2wyY2FwLmg+ CiAjaW5jbHVkZSA8bmV0Z3JhcGgvYmx1ZXRvb3RoL2luY2x1ZGUvbmdfYnRzb2NrZXQuaD4KKyNp bmNsdWRlIDx0aW1lLmg+CiAKIF9fQkVHSU5fREVDTFMKIApAQCAtMTI5LDggKzEzMSw0MiBAQAog CXVpbnQ4X3QJCV9wYWRkaW5nWzIwXTsJLyogbGVhdmUgc3BhY2UgZm9yIGZ1dHVyZSBhZGRpdGlv bnMgKi8KIH07CiAKK3N0cnVjdCBidF9kZXZyZXEKK3sKKwl1aW50MTZfdAlvZ2Y7CisJdWludDE2 X3QJb2NmOworCWludAkJZXZlbnQ7CisJdm9pZAkJKmNwYXJhbTsKKwlpbnQJCWNsZW47CisJdm9p ZAkJKnJwYXJhbTsKKwlpbnQJCXJsZW47Cit9OworCitzdHJ1Y3QgYnRfZGV2ZmlsdGVyIHsKKwl1 aW50NjRfdAlldmVudF9tYXNrOworCXVpbnQ4X3QJCXBhY2tldF9tYXNrOworfTsKKworc3RydWN0 IGJ0X2RldmlucXVpcnkgeworCWJkYWRkcl90CWJkYWRkcjsKKwl1aW50OF90CQlwc2Nhbl9yZXBf bW9kZTsKKwl1aW50OF90CQlwc2Nhbl9wZXJpb2RfbW9kZTsKKwl1aW50OF90CQlwc2Nhbl9tb2Rl OworCXVpbnQ4X3QJCWRldl9jbGFzc1szXTsKKwl1aW50MTZfdAljbG9ja19vZmZzZXQ7Cit9Owor CiB0eXBlZGVmIGludAkoYnRfZGV2ZW51bV9jYl90KShpbnQsIHN0cnVjdCBidF9kZXZpbmZvIGNv bnN0ICosIHZvaWQgKik7CiAKK2ludAkJYnRfZGV2b3BlbiAoY2hhciBjb25zdCAqZGV2bmFtZSk7 CitpbnQJCWJ0X2RldmNsb3NlKGludCBzKTsKK2ludAkJYnRfZGV2c2VuZCAoaW50IHMsIHVpbnQx Nl90IG9nZiwgdWludDE2X3Qgb2NmLCBpbnQgcGxlbiwgdm9pZCAqcGFyYW0pOworaW50CQlidF9k ZXZyZWN2IChpbnQgcywgdWludDhfdCAqYnVmLCBpbnQgc2l6ZSwgdGltZV90IHRvKTsKK2ludAkJ YnRfZGV2cmVxICAoaW50IHMsIHN0cnVjdCBidF9kZXZyZXEgKnIsIHRpbWVfdCB0byk7CitpbnQJ CWJ0X2RldmZpbHRlcihpbnQgcywgc3RydWN0IGJ0X2RldmZpbHRlciBjb25zdCAqbmV3LAorCQkJ ICAgICBzdHJ1Y3QgYnRfZGV2ZmlsdGVyICpvbGQpOworaW50CQlidF9kZXZpbnF1aXJ5KGNoYXIg Y29uc3QgKmRldm5hbWUsIGludCBsZW5ndGgsIGludCBudW1fcnNwLAorCQkJICAgICAgdWludDhf dCBjb25zdCAqbGFwLCBzdHJ1Y3QgYnRfZGV2aW5xdWlyeSAqKmlpKTsKIGludAkJYnRfZGV2aW5m byAoc3RydWN0IGJ0X2RldmluZm8gKmRpKTsKIGludAkJYnRfZGV2ZW51bSAoYnRfZGV2ZW51bV9j Yl90ICpjYiwgdm9pZCAqYXJnKTsKIApJbmRleDogTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTWFr ZWZpbGUJKHJldmlzaW9uIDE5MDg3MCkKKysrIE1ha2VmaWxlCSh3b3JraW5nIGNvcHkpCkBAIC0z Myw2ICszMywxMyBAQAogTUxJTktTKz0JYmx1ZXRvb3RoLjMgYnRfZGV2aW5mby4zCiBNTElOS1Mr PQlibHVldG9vdGguMyBidF9kZXZlbnVtLjMKIAorTUxJTktTKz0JYmx1ZXRvb3RoLjMgYnRfZGV2 b3Blbi4zCitNTElOS1MrPQlibHVldG9vdGguMyBidF9kZXZjbG9zZS4zCitNTElOS1MrPQlibHVl dG9vdGguMyBidF9kZXZzZW5kLjMKK01MSU5LUys9CWJsdWV0b290aC4zIGJ0X2RldnJlcS4zCitN TElOS1MrPQlibHVldG9vdGguMyBidF9kZXZmaWx0ZXIuMworTUxJTktTKz0JYmx1ZXRvb3RoLjMg YnRfZGV2aW5xdWlyeS4zCisKIE1MSU5LUys9CWJsdWV0b290aC4zIGJkYWRkcl9zYW1lLjMKIE1M SU5LUys9CWJsdWV0b290aC4zIGJkYWRkcl9hbnkuMwogTUxJTktTKz0JYmx1ZXRvb3RoLjMgYmRh ZGRyX2NvcHkuMwo= --001636164aa7ee85e0046726e214-- From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 9 23:26:15 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 7A9B5106564A for ; Thu, 9 Apr 2009 23:26:15 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 36C4C8FC1C for ; Thu, 9 Apr 2009 23:26:15 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so556355ywh.13 for ; Thu, 09 Apr 2009 16:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=rTgLFa4kE4GjNUvzwwhQCWKKvKTMQPCfvgH7HBsuq7w=; b=jafQ2ZTFMwCHLDydfEQy5FvkqXDf3ISvGJ6OyxDKbZMaNachRcjmPfBHBBkN+4aAz7 HgN8GUQRg6jx4lo0PG8UiCI2wsfhmN9Cxfhh0MZMTFN2cvFs6jK4eBl5HsH/XX9BK2cc qMt4qIi6Exc0QkODTyLwjwUPGQ/F0sOKPRb4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=IRMK0qe0E3MMJO+E1Wj9oKvGNczLwMQW1YywFFUCZoKx3/fTR/E1mrOkOgnEbbgYay bk705u9MsjMtErpHVMpEOOu2zEN3EFPJ/GL+7rJbS7hvXQVPF/z+3Y42Sg9i20ClbBzm nUZk1CfEXcbp5FRHn4cmw5pmiLQrwaAa1yp3k= MIME-Version: 1.0 Received: by 10.90.49.3 with SMTP id w3mr3647199agw.44.1239319574683; Thu, 09 Apr 2009 16:26:14 -0700 (PDT) Date: Thu, 9 Apr 2009 15:26:14 -0800 Message-ID: From: Maksim Yevmenkin To: "freebsd-bluetooth@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: obexapp 1.4.11 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: Thu, 09 Apr 2009 23:26:15 -0000 dear freebsd-bluetooth@ users, new version of obexapp can be download from http://www.geocities.com/m_evmenkin/obexapp-1.4.11.tar.gz it includes minor enhancement submitted by Mikhail T to remove warning about use mktemp(). Guido, please update the port. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Thu Apr 9 23:29:11 2009 Return-Path: Delivered-To: bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23FD2106566B for ; Thu, 9 Apr 2009 23:29:11 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id D11658FC17 for ; Thu, 9 Apr 2009 23:29:10 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk24 with SMTP id 24so2469730gxk.19 for ; Thu, 09 Apr 2009 16:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/Vvk7axo8tE6R+JLtYdtblv6IN//uhEY1Bojk/NK/nQ=; b=LIEEwhE96Nwi6DWkOChVzMTGbo3m7jNNtl4YbhSMVA/NV9LF66JSUcImp+CKtpAIxO UcBIyRzyzLT099APR+17rlGNfQ3iQzsmHZE5BQLDYdjWwh1INMlNtwqOifruXh7x9W6d B/IXY9IYWk39kkMiAC/yezaGD94ftw+1RYSgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YPuJyhAy9ki9RmLBPJysuIob8K68Yoxyvg2MW9STqq60o4/msWIEKr0hEFWm8K/slv WhuNbtZl/2RsmABsXz3MNK+JP2BAz24SxLmRMYDCubBewyXgp/MkryhMVArpDcyLgRxu 23AiXmSk/ntdK9E/RQbXbnasXnEE38KgEKi5g= MIME-Version: 1.0 Received: by 10.90.98.12 with SMTP id v12mr3640428agb.17.1239317842121; Thu, 09 Apr 2009 15:57:22 -0700 (PDT) In-Reply-To: <49DE5ECD.8020202@aldan.algebra.com> References: <49DE5ECD.8020202@aldan.algebra.com> Date: Thu, 9 Apr 2009 14:57:22 -0800 Message-ID: From: Maksim Yevmenkin To: "Mikhail T." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: bluetooth@freebsd.org Subject: Re: per-user directories for obexapp-server 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: Thu, 09 Apr 2009 23:29:11 -0000 On Thu, Apr 9, 2009 at 12:47 PM, Mikhail T. wrote: > Hello! > > I was able to set up the Bluetooth-server on my main machine, but all of > the pushed files (Object Pushed) end up in the same root-only > directory... Is there, perhaps, a way to specify a different directory > for each device-ID (bdaddr)? not at the moment, no. > This way my wife and myself could have our own locations (under > home-directories somewhere) for pictures and phonebook backups... > Please, advise. Thanks! Yours, > > -mi > > P.S. Maybe, the hcsecd.conf's syntax can be extended to (optionally) > provide the username associated with each listed device? technically, nothing prevents you from running 2 or more instances of obexapp on different rfcomm channels. each instance would use different root directory. this way each of you can use service on different rfcomm channel to push data into appropriate root directory. i guess its possible to teach obexapp about mapping between client's bdaddr and root directory. ideally, of course, what we want it to have credentials passed over obex connection so the server knows exactly who is talking to it, but that, of course, will likely never happen :) thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Fri Apr 10 07:53:36 2009 Return-Path: Delivered-To: bluetooth@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D50E106566B for ; Fri, 10 Apr 2009 07:53:36 +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 F342C8FC0C for ; Fri, 10 Apr 2009 07:53:35 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1LsBHg-0006wY-Fe; Fri, 10 Apr 2009 08:36:20 +0100 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26397-09; Fri, 10 Apr 2009 08:36:20 +0100 (BST) Received: from [10.216.29.42] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1LsBHe-0006wL-LS; Fri, 10 Apr 2009 08:36:20 +0100 Received: (nullmailer pid 964 invoked by uid 1000); Fri, 10 Apr 2009 07:35:04 -0000 Date: Fri, 10 Apr 2009 08:35:04 +0100 (BST) To: "Mikhail T\." In-Reply-To: <49DE5ECD.8020202@aldan.algebra.com> References: <49DE5ECD.8020202@aldan.algebra.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1239348904.587506.623.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: bluetooth@FreeBSD.org Subject: Re: per-user directories for obexapp-server 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 07:53:36 -0000 On Thu, 9 Apr 2009, Mikhail T. wrote: > I was able to set up the Bluetooth-server on my main machine, but all of > the pushed files (Object Pushed) end up in the same root-only > directory... Is there, perhaps, a way to specify a different directory > for each device-ID (bdaddr)? One trouble with bluetooth is that there is no finer identification than 'device id', so a multi-user system ends up allowing access by any user to all known devices. This could likely be worked out, I had some ideas about passing credentials around in the kernel to enable marking baseband links as private, and having link keys stored in users home directories but I'm not sure the effort required would be worth it as most systems (with bluetooth) are single-concurrent-user anyway. In the meantime I would suggest something like having a ttyaction(5) mechanism to arrange something like mount -t null -o mount /var/obex ${HOME}/obex for the user logged in on the console, so that incoming files are stored the logged in users directory (or /var/obex if nobody is logged in at the console). iain 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 From owner-freebsd-bluetooth@FreeBSD.ORG Fri Apr 10 10:32:00 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 652F2106564A for ; Fri, 10 Apr 2009 10:32:00 +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 0ACB28FC08 for ; Fri, 10 Apr 2009 10:31:59 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1LsE1b-0008Md-9p; Fri, 10 Apr 2009 11:31:55 +0100 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31934-05; Fri, 10 Apr 2009 11:31:54 +0100 (BST) Received: from [10.216.29.42] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1LsE1Z-0008MH-Ev; Fri, 10 Apr 2009 11:31:54 +0100 Received: (nullmailer pid 872 invoked by uid 1000); Fri, 10 Apr 2009 10:30:36 -0000 Date: Fri, 10 Apr 2009 11:30:36 +0100 (BST) To: Bruce Simpson In-Reply-To: <49DE4F44.8070707@incunabulum.net> References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <49DE4F44.8070707@incunabulum.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1239359436.893706.893.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" Subject: Re: Speeding up device discovery: paper 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 10:32:00 -0000 On Thu, 9 Apr 2009, Bruce Simpson wrote: > I keep wishing Bluetooth had passive scanning like 802.11 does. I always thought that was what 'periodic inquiry' was supposed to be, that a device would take time every n seconds to do a quick neighbor discovery.. btw something you might run into with multiple radios is that I find creating a baseband link does not always work first time, but if the radio has seen the other device recently via inquiry, it can connect very quickly. I'm not sure if this is the radio recording some information about the remote device or that the OS reusing the clock offset is helping, but neither will help if you have one radio doing the inquiry and the other doing the paging.. iain From owner-freebsd-bluetooth@FreeBSD.ORG Fri Apr 10 18:14:39 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 4EFF2106567E for ; Fri, 10 Apr 2009 18:14:39 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0D8D58FC17 for ; Fri, 10 Apr 2009 18:14:39 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id A4F11315622; Fri, 10 Apr 2009 14:14:38 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 10 Apr 2009 14:14:38 -0400 X-Sasl-enc: 9w4uQuMyI2hOw5x2jq8682wjXp6kNxeAonNK7+EcAQEM 1239387278 Received: from empiric.lon.incunabulum.net (unknown [81.168.51.182]) by mail.messagingengine.com (Postfix) with ESMTPSA id 82F8F31FE3; Fri, 10 Apr 2009 14:14:37 -0400 (EDT) Message-ID: <49DF8C8C.5030006@incunabulum.net> Date: Fri, 10 Apr 2009 19:14:36 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.19 (X11/20090126) MIME-Version: 1.0 To: Iain Hibbert References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <49DE4F44.8070707@incunabulum.net> <1239359436.893706.893.nullmailer@galant.ukfsn.org> In-Reply-To: <1239359436.893706.893.nullmailer@galant.ukfsn.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" , "alexei@raylab.com" Subject: Re: Speeding up device discovery: paper 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 18:14:39 -0000 Iain Hibbert wrote: > On Thu, 9 Apr 2009, Bruce Simpson wrote: > >> I keep wishing Bluetooth had passive scanning like 802.11 does. >> > I always thought that was what 'periodic inquiry' was supposed to be, that > a device would take time every n seconds to do a quick neighbor > discovery.. > Over the last 24 hours or so I've digested a number of interesting research papers on the subject... What is clear is that inquiry is perhaps the most expensive Bluetooth operation possible, in terms of power and baseband behaviour. The IrDA paper makes it clear that session initiation may still be faster if you can communicate the BD_ADDR of the station using a side-band, in this case, IrDA. However, this paper makes it clear that the 10.24s inquiry time quoted by the Bluetooth spec may be excessive, although their figures are based on models, not experimental work: Bluetooth Inquiry Time Characterization and Selection Peterson/Baldwin/Kharoufeh http://netlab.cs.ucla.edu/wiki/files/01661527.pdf In this paper they do mention that using the Bluetooth V1.2 'Interlaced Inquiry Scan' feature can improve discovery times for each station by several *seconds*, but of course making sure it's turned on depends entirely on your station vendor. ...of course, every time you want to turn stuff like this on, you are either relying on the host controller to turn it on for you, or you need to send explicit HCI commands to the HC to bring it up (Errg, libhci!) It is also a pity that you never get an HCI event from your HC when it enters Inquiry Scan state and actually responds to an inquiry -- but then again the Inquiry protocol is asymmetric, it's not peer-to-peer, it's a bit like ARP without any source/destination field on a purely broadcast medium, and you never get to find out anything about who inquires or why, so Inquiry presents no opportunities for passive endpoint discovery. Yuck. I haven't read far enough to determine what kind of admission control exists, if any, for preventing pre-V1.2 station(s) from forming an adjacency with the station(s) which one is running. It seems analogous to the problems caused by admitting 802.11b STAs into an 802.11a/g capable ESS. It would be nice if EDR use could be forced, although obviously that isn't backwards compatible. Of course, if any of this stuff were easy, everyone would be doing it by now. > btw something you might run into with multiple radios is that I find > creating a baseband link does not always work first time, but if the radio > has seen the other device recently via inquiry, it can connect very > quickly. I'm not sure if this is the radio recording some information > about the remote device or that the OS reusing the clock offset is > helping, but neither will help if you have one radio doing the inquiry and > the other doing the paging.. > That probably needs further inspection at baseband layer to figure out what's going on. It is more than likely that the host controller is tracking some info about the peer in some internal cache... I find that PalmOS 5 devices always try to inquire first, even if you have an entry in the persistent neighbour cache with which you could page. Paging is always more efficient than Inquiry, but of course requires you know the BD_ADDR. Nokia Series 60 handsets seem to do much better and can page with what they already have, in fact, out of most of the handsets I've worked with, Nokia's Bluetooth support seems more mature. cheers BMS From owner-freebsd-bluetooth@FreeBSD.ORG Sat Apr 11 18:01:11 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 E079A106564A for ; Sat, 11 Apr 2009 18:01:11 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id AD5EF8FC1A for ; Sat, 11 Apr 2009 18:01:11 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 2A3B9317064; Sat, 11 Apr 2009 14:01:10 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 11 Apr 2009 14:01:11 -0400 X-Sasl-enc: UlNb8A1BjIb5Qoi9w/BRPN0iy6tLhuKIK9K5pqBKh2Vj 1239472870 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 82E9CCD38; Sat, 11 Apr 2009 14:01:09 -0400 (EDT) Message-ID: <49E0DAE2.3030805@incunabulum.net> Date: Sat, 11 Apr 2009 19:01:06 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Iain Hibbert References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <49DE4F44.8070707@incunabulum.net> <1239359436.893706.893.nullmailer@galant.ukfsn.org> <49DF8C8C.5030006@incunabulum.net> In-Reply-To: <49DF8C8C.5030006@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" , "alexei@raylab.com" Subject: BlueZ dbus binding is device dependent 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: Sat, 11 Apr 2009 18:01:12 -0000 Hi, So, just to confirm, I read the code examples in this BlueZ Wiki article; and it does indeed appear that the naming convention BlueZ uses in DBus is BlueZ dependent:- http://wiki.bluez.org/wiki/HOWTO/DiscoveringDevices Hmmm! Whatever do we do about that. BMS From owner-freebsd-bluetooth@FreeBSD.ORG Sat Apr 11 19:07:21 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 09DBB106567C for ; Sat, 11 Apr 2009 19:07:21 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id 955AE8FC19 for ; Sat, 11 Apr 2009 19:07:20 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.t-mobile.co.uk with esmtp (Exim 4.50) id 1LsiXr-0006fT-8g; Sat, 11 Apr 2009 20:07:15 +0100 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25404-03; Sat, 11 Apr 2009 20:07:14 +0100 (BST) Received: from [10.214.167.244] (helo=rya-online.net) by localhost.t-mobile.co.uk with smtp (Exim 4.50) id 1LsiXo-0006fO-Ex; Sat, 11 Apr 2009 20:07:14 +0100 Received: (nullmailer pid 1522 invoked by uid 1000); Sat, 11 Apr 2009 19:05:54 -0000 Date: Sat, 11 Apr 2009 20:05:54 +0100 (BST) To: Bruce Simpson In-Reply-To: <49E0DAE2.3030805@incunabulum.net> References: <49D92E26.2030508@incunabulum.net> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <49DE4F44.8070707@incunabulum.net> <1239359436.893706.893.nullmailer@galant.ukfsn.org> <49DF8C8C.5030006@incunabulum.net> <49E0DAE2.3030805@incunabulum.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1239476754.337291.1460.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 localhost.t-mobile.co.uk); SAEximRunCond expanded to false Cc: "freebsd-bluetooth@freebsd.org" , "alexei@raylab.com" Subject: Re: BlueZ dbus binding is device dependent 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: Sat, 11 Apr 2009 19:07:21 -0000 On Sat, 11 Apr 2009, Bruce Simpson wrote: > So, just to confirm, I read the code examples in this BlueZ Wiki article; > and it does indeed appear that the naming convention BlueZ uses in DBus is > BlueZ dependent:- > http://wiki.bluez.org/wiki/HOWTO/DiscoveringDevices first, that API may not be the same as the BlueZ 4.x series which I think has been evolving. The wiki main page says the API is best defined by the documents in the bluez releases. second, I'm not sure if it is a total disaster. The device being referenced is at least a string "/org/bluez/hci0" rather than the integer dev_id that the bluez library uses. That can be worked on fairly easily, plus I might have seen a comment on the bluez list (which I subscribed to but don't really read) that hardcoded defs are to be frowned on, I think there is a way to find local devices. Then, the module name "org.bluez" is probably not needed to change - for instance if a GNOME application uses the bluez dbus module, I think that all calls end up passed to bluetoothd and 'all that is required' is having a bluez compatible bluetoothd. Whether the bluez bluetoothd can be easily patched or if a fork or a rewrite is required I don't know. I looked at the bluez sources but I don't have any context for it so am just confused.. iain