One AF_* constant for each of sockaddr_{hci,l2cap,rfcomm}?

[Maksim Yevmenkin]

On 8/31/07, Iain Hibbert <plunky at rya-online.net> wrote:
> On Thu, 30 Aug 2007, Maksim Yevmenkin wrote:
>
> > On 8/30/07, Eugene M. Kim <freebsd.org at 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.. :)

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
>