From owner-freebsd-bluetooth@FreeBSD.ORG Thu Aug 30 22:49:00 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 8400016A417 for ; Thu, 30 Aug 2007 22:49:00 +0000 (UTC) (envelope-from freebsd.org@ab.ote.we.lv) Received: from mx0.nttmcl.com (MX0.nttmcl.com [216.69.68.201]) by mx1.freebsd.org (Postfix) with ESMTP id 4A0EB13C45B for ; Thu, 30 Aug 2007 22:49:00 +0000 (UTC) (envelope-from freebsd.org@ab.ote.we.lv) Received: from bbq.nttmcl.com (bbq.nttmcl.com [216.69.70.43]) by mx0.nttmcl.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l7UMT7sC007868 for ; Thu, 30 Aug 2007 15:29:09 -0700 Message-ID: <46D744B3.8080107@ab.ote.we.lv> Date: Thu, 30 Aug 2007 15:29:07 -0700 From: "Eugene M. Kim" User-Agent: Thunderbird 2.0.0.0 (X11/20070524) MIME-Version: 1.0 To: FreeBSD Bluetooth Mailing List Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Subject: 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: Thu, 30 Aug 2007 22:49:00 -0000 Hello, It seems that AF_BLUETOOTH ambiguously identifies three different types=20 of socket=E2=80=94HCI, L2CAP and RFCOMM=E2=80=94each with its own sockadd= r_* type. This=20 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=20 turn, break usage of system calls such as getsockname(2) and=20 getpeername(2): These calls return a struct sockaddr whose sa_family=20 should uniquely and unambiguously identify the real sockaddr_* struct to = which the returned sockaddr should be type-cast; if sa_family =3D=3D=20 AF_BLUETOOTH, there are three possibilities and an application that=20 calls get{sock,peer}name(2) cannot choose one of them without extra=20 information (namely, the third argument to the socket() call that=20 created the socket). In this light, shouldn't a unique AF_* constant be allocated for each=20 Bluetooth socket type, such as AF_BTHCI, AF_BTL2CAP and AF_BTRFCOMM,=20 instead of just one AF_BLUETOOTH? Regards, Eugene From owner-freebsd-bluetooth@FreeBSD.ORG Fri Aug 31 01:12:27 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 6EC5416A417 for ; Fri, 31 Aug 2007 01:12:27 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by mx1.freebsd.org (Postfix) with ESMTP id F160713C442 for ; Fri, 31 Aug 2007 01:12:26 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so511709mue for ; Thu, 30 Aug 2007 18:11:57 -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=eN8IW8ZJrzFSMt5h/RwH96jrjhjI4TQH1gw0S7bZpOwfcE/7KfYh1mimiN+3aVCRqxU821WEr1kz0O9kMVp+KXEW2SbKzvs86rGX25ZMtXtRGlXmE3mUXYCpJjBZmLMtNjcbIT6mu28p5zNuAGLehIFWCOC8BCnojlg+EfQXzOM= 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=kvvC85T+g7VD5nakvmDlPoAKthip3rZxiP6yJnCGiDDoz7o3O9z9qgUcD0XUuLRUGc677vUBkYXLsD4frUdJ2LYpcFa/cHDDbJczsmLkDNSl/Jek27N0+/PYPFRO1fbdqmOMZy/LN3X+xIHNtT+blXK5zxA7/EsJF9y1qvtBbUw= Received: by 10.86.84.5 with SMTP id h5mr824475fgb.1188520989356; Thu, 30 Aug 2007 17:43:09 -0700 (PDT) Received: by 10.86.63.16 with HTTP; Thu, 30 Aug 2007 17:43:09 -0700 (PDT) Message-ID: Date: Thu, 30 Aug 2007 17:43:09 -0700 From: "Maksim Yevmenkin" To: "Eugene M. Kim" In-Reply-To: <46D744B3.8080107@ab.ote.we.lv> MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <46D744B3.8080107@ab.ote.we.lv> Cc: 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 01:12:27 -0000 On 8/30/07, Eugene M. Kim wrote: > Hello, > > It seems that AF_BLUETOOTH ambiguously identifies three different types > of socket=97HCI, L2CAP and RFCOMM=97each with its own sockaddr_* type. T= his > 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 =3D=3D > 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. > 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? thanks, max 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