Date: Thu, 30 Aug 2007 17:43:09 -0700
From: "Maksim Yevmenkin" <maksim.yevmenkin@gmail.com>
To: "Eugene M. Kim" <freebsd.org@ab.ote.we.lv>
Cc: FreeBSD Bluetooth Mailing List <bluetooth@freebsd.org>
Subject: Re: One AF_* constant for each of sockaddr_{hci,l2cap,rfcomm}?
Message-ID: <bb4a86c70708301743y64ea891dk11e8f1ad925d92c8@mail.gmail.com>
In-Reply-To: <46D744B3.8080107@ab.ote.we.lv>
References: <46D744B3.8080107@ab.ote.we.lv>
next in thread | previous in thread | raw e-mail | index | archive | help
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=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70708301743y64ea891dk11e8f1ad925d92c8>