From owner-freebsd-bluetooth@FreeBSD.ORG Fri Aug 31 23:59:47 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 A8D8516A421 for ; Fri, 31 Aug 2007 23:59:47 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smarthost01.eng.net (smarthost01.eng.net [213.130.146.173]) by mx1.freebsd.org (Postfix) with ESMTP id 47E9713C480 for ; Fri, 31 Aug 2007 23:59:47 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from netmail01.eng.net ([213.130.128.38] helo=rya-online.net) by smarthost01.eng.net with smtp (Exim 4.62) (envelope-from ) id 1IRC0T-000722-1f; Fri, 31 Aug 2007 20:18:19 +0100 Received: (nullmailer pid 728 invoked by uid 1000); Fri, 31 Aug 2007 19:16:28 -0000 Date: Fri, 31 Aug 2007 20:16:27 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: References: <46D744B3.8080107@ab.ote.we.lv> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1188587788.301999.1317.nullmailer@galant.ukfsn.org> From: Iain Hibbert 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: Fri, 31 Aug 2007 23:59:47 -0000 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.. :) > > 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) regards, iain