From owner-freebsd-bluetooth@FreeBSD.ORG Mon Sep 3 16:22:11 2007 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 4778316A417 for ; Mon, 3 Sep 2007 16:22:11 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id BFB2313C442 for ; Mon, 3 Sep 2007 16:22:10 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so1197312nfd for ; Mon, 03 Sep 2007 09:22:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dfX3vKNqSeKSfG/J4AllFGV2cL8+90JC94Eoik39+rcTjqp5Kb23+uXFAKLD5h8rID/YJiIoC7KdFIhdAXni5o3ieDqxr7X1LTCsAIUuzh1fO0ayvYlvjhA3q3SnT01RnTbCjcpFRrm2uhVZtQifstqDHYzOoOOiqwfJxn3poh4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Bed/Q+jgSj6A/Zv1OtkAU7Lgy6GyZhwmq025CfpL45C2PeY1fARXbk5I3lcrRF5/M4QNoW3rC2yCEEqHCjC25kejm4446V/WfIXa7+dpI1Q/UZ7N3E2fPY0GuG0yOzr6kebgrw9BN7bESg9L/38omiKtSXyyFUvFVgdza53+AA8= Received: by 10.86.62.3 with SMTP id k3mr3552922fga.1188836529369; Mon, 03 Sep 2007 09:22:09 -0700 (PDT) Received: by 10.86.63.16 with HTTP; Mon, 3 Sep 2007 09:22:09 -0700 (PDT) Message-ID: Date: Mon, 3 Sep 2007 09:22:09 -0700 From: "Maksim Yevmenkin" To: "Iain Hibbert" In-Reply-To: <1188587788.301999.1317.nullmailer@galant.ukfsn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46D744B3.8080107@ab.ote.we.lv> <1188587788.301999.1317.nullmailer@galant.ukfsn.org> Cc: "Eugene M. Kim" , FreeBSD Bluetooth Mailing List Subject: Re: One AF_* constant for each of sockaddr_{hci,l2cap,rfcomm}? 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, 03 Sep 2007 16:22:11 -0000 On 8/31/07, Iain Hibbert wrote: > On Thu, 30 Aug 2007, Maksim Yevmenkin wrote: > > > On 8/30/07, Eugene M. Kim wrote: > > > Hello, > > > > > > It seems that AF_BLUETOOTH ambiguously identifies three different types > > > of socket?HCI, L2CAP and RFCOMM?each with its own sockaddr_* type. This > > > deviates from the standard practice where there is a 1:1 mapping between > > > an AF_* constant and a corresponding sockaddr_* type, and this may, in > > > turn, break usage of system calls such as getsockname(2) and > > > getpeername(2): These calls return a struct sockaddr whose sa_family > > > should uniquely and unambiguously identify the real sockaddr_* struct to > > > which the returned sockaddr should be type-cast; if sa_family == > > > AF_BLUETOOTH, there are three possibilities and an application that > > > calls get{sock,peer}name(2) cannot choose one of them without extra > > > information (namely, the third argument to the socket() call that > > > created the socket). > > > > the application probably can use sa_len field to figure out which > > sockaddr_ structure it is. it is somewhat a hack but it should work. > > Seems dangerous to me. What if the architecture* does not have byte > aligned memory access, and the compiler expands the uint8_t's to words? > l2cap and rfcomm would become the same length in that case. > > * (I don't know if there exists such an architecture in common use.. :) i did say it was a hack :) > > > In this light, shouldn't a unique AF_* constant be allocated for each > > > Bluetooth socket type, such as AF_BTHCI, AF_BTL2CAP and AF_BTRFCOMM, > > > instead of just one AF_BLUETOOTH? > > > > i'd rather not to it. may be it is better to add sa_proto field to > > bluetooth sockaddr_ structures and have union data field for each > > protocol? > > better (IMHO :) if you are breaking backwards compatibility, to use the > structure that NetBSD is already using for all AF_BLUETOOTH socket > addresses: > > /* > * Socket address used by Bluetooth protocols > */ > struct sockaddr_bt { > uint8_t bt_len; > sa_family_t bt_family; > bdaddr_t bt_bdaddr; > uint16_t bt_psm; > uint8_t bt_channel; > uint8_t bt_zero[5]; > }; > > (unused fields are ignored by protocols and should be set to zero) well, going back to the original email, i'm not sure what author is trying to do. lets say it is for a hypothetical application that has access to the socket file descriptor and wants to identify protocol (socket type) behind the socket and print some information (for example lsof of something like that). if that is the case, then yes, AF_BLUETOOTH does not tell you which protocol (socket type) is used. however, neither does sockaddr_bt from netbsd, and, for that matter, neither does sockaddr_in. getsockname() does not tell you anything about protocol (socket type) (for example IPPROTO_TCP vs. IPPROTO_UDP). that is why i suggested so_proto field. i can see how netbsd's sockaddr_bt could be more convenient (or confusing depending on one's point of view) for a programmer. if author of the original email was simply making an observation, that is ok too. thanks, max > > regards, > iain >