Hi,
   As part of my bluetooth stack for NetBSD (please hold your breath a
while longer :), one of the decisions I made early on was that the
sockaddr_bt structure that I use is a flat structure and is constant
throughout the protocol family.

like so:

/*
 * Socket address used by Bluetooth protocols
 */
struct sockaddr_bt {
	uint8_t		bt_len;		/* sizeof(sockaddr_bt) */
	sa_family_t	bt_family;	/* AF_BLUETOOTH */
	bdaddr_t	bt_bdaddr;	/* uint8_t[6] */
	uint16_t	bt_psm;
	uint8_t		bt_channel;
};

Now, I've been talking with the FreeBSD folks a little, and they dont do
this, they (and incidentally, the linux protocol stacks) use a separate
structure for each sub protocol:

struct sockaddr_hci {
	uint8_t		hci_len;
	uint8_t		hci_family;
	uint8_t		hci_name[32];
};

struct sockaddr_l2cap {
	uint8_t		l2cap_len;
	sa_family_t	l2cap_family;
	bdaddr_t	l2cap_bdaddr;
	uint16_t	l2cap_psm;
};

struct sockaddr_rfcomm {
	uint8_t		rfcomm_len;
	sa_family_t	rfcomm_family;
	uint8_t		rfcomm_channel;
	bdaddr_t	rfcomm_bdaddr;
};

In each of these, they use AF_BLUETOOTH as the family which just seems
wrong to me. I am fairly new to this socket programming but have the idea
that the 'family type' should describe the sockaddr structure. You look at
the tag and you know how to interpret it.

the reason for the _hci difference is, as far as I can see, that bluetooth
devices do not give a device address until they are enabled and asked for
one, so you can't talk to it via bdaddr until you have enabled it. I have
ioctls for this, which index on the device name and the init is handled by
the kernel so its not a problem.

the l2cap/rfcomm difference is less clear - l2cap does not use the
rfcomm_channel value (but its easy to ignore), whereas rfcomm can use the
l2cap_psm value to set up separate sessions (and does, in my
implementation)

Now, for ease of use I prefer the single structure, as address information
can be passed along to the next level without change. It does introduce a
slight incompatibility though I prefer 'right' over 'conformant', but is
it right?

There are other incompatibilites in any case, though porting programs is
usually a bit of cut and paste and a lot of it could be handled with
#define. I'm not sure what application level software is available but
that would not usually need to access HCI devices directly, though there
was some chat on the FreeBSD list a while ago about creating a library API
to abstract some of that which could make sense.

If anybody has any opinions (on this :), please let me have them..

iain