Date: Fri, 31 Aug 2007 20:16:27 +0100 (BST)
From: Iain Hibbert <plunky@rya-online.net>
To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com>
Cc: "Eugene M. Kim" <freebsd.org@ab.ote.we.lv>, FreeBSD Bluetooth Mailing List <bluetooth@freebsd.org>
Subject: Re: One AF_* constant for each of sockaddr_{hci,l2cap,rfcomm}?
Message-ID: <1188587788.301999.1317.nullmailer@galant.ukfsn.org>
In-Reply-To: <bb4a86c70708301743y64ea891dk11e8f1ad925d92c8@mail.gmail.com>
References: <46D744B3.8080107@ab.ote.we.lv> <bb4a86c70708301743y64ea891dk11e8f1ad925d92c8@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 Aug 2007, Maksim Yevmenkin wrote:
> On 8/30/07, Eugene M. Kim <freebsd.org@ab.ote.we.lv> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1188587788.301999.1317.nullmailer>