whitespace

[Iain Hibbert]

On Tue, 7 Mar 2006, Maksim Yevmenkin wrote:

> another union inside _hci part?

I think too many unions. Is the amount of padding really 32 bytes? (I
think only 14 for NetBSD) how long can the netgraph node name be? any
reason you can't just use a flat structure?

struct {
	uint8_t		len
	sa_family_t	family
	bdaddr_t	bdaddr
	uint16_t	psm
	uint8_t		channel
	char		name[16]
	uint8_t		_pad[7]
}

with this, you still get 34 bytes total and can have up to 23 bytes for
the nodename (for HCI). Is there a reason to suppose that it should all be
squashed up at the top of the structure in every instance?

could also be

struct {
	uint8_t		len
	sa_family_t	family
	union {
		uint8_t		_pad[32]
		char		name[nn]
		struct {
			bdaddr_t	bdaddr
			uint16_t	psm
			uint8_t		channel
		} bar
	} foo
}

#define bt_name		foo.name
#define bt_bdaddr	foo.bar.bdaddr
#define bt_psm		foo.bar.psm
#define bt_channel	foo.bar.channel

My thought also is that if you split it up so each protocol has a separate
section, you can't specify the offset of a field that appears in multiple
sections (such as bdaddr) in a generic way since it would exist in more
than one namespace, and my desire for a single namespace was what started
this :)

Hm, it occurs to me though that I am only thinking of source level
compatibility, were you considering binary compat? That probably
introduces additional considerations.

> > Also, it is possible in my implementation to specify an alternate PSM for
> > rfcomm sockets (as I read the spec, this is allowed..)
>
> sure its allowed, but why would you want to do this? there is no way for the
> remote device to know that the local device runs rfcomm on some other (than 3)
> psm. in the same way you could run sdp on any psm. it will work, as long as
> you control both sides - server and client. changing "well known" psm is a
> sure way to get into all sorts of interoperability problems.

Well, I am not well versed in SDP because your libsdp managed to hide the
details for me, but for example the SDP query on my phone produces this
now:

Record Handle: 0x00010000
Service Class ID List:
	Dial-Up Networking (0x1103)
	Generic Networking (0x1201)
Protocol Descriptor List:
	L2CAP (0x0100)
	RFCOMM (0x0003)
		Protocol specific parameter #1: u/int8/bool 1
Bluetooth Profile Descriptor List:
	Dial-Up Networking (0x1103) ver. 1.0


whereas if it produced something like:

Record Handle: 0x00010000
Service Class ID List:
	Dial-Up Networking (0x1103)
	Generic Networking (0x1201)
Protocol Descriptor List:
	L2CAP (0x0100)
	(0x1007)
		Protocol specific parameter #1: u/int8/bool 1
Bluetooth Profile Descriptor List:
	Dial-Up Networking (0x1103) ver. 1.0

then it should 'just work' on psm 0x1007, no?

Thats how I read it from "5.1.5 ProtoclDescriptorListAttribute" anyway but
I havent tried it..

And, as to why somebody might want to do this, I dont know but it was easy
to allow so I did :)

iain