Date: Wed, 8 Mar 2006 08:52:11 +0000 (GMT) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: whitespace Message-ID: <1141807931.899207.8150.nullmailer@galant.ukfsn.org> In-Reply-To: <440E2D3F.6040800@savvis.net> References: <1141762244.118700.5588.nullmailer@galant.ukfsn.org> <440DEE78.5020500@savvis.net> <1141767948.252179.12317.nullmailer@galant.ukfsn.org> <440E0233.7080703@savvis.net> <1141775918.215241.15084.nullmailer@galant.ukfsn.org> <440E2D3F.6040800@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1141807931.899207.8150.nullmailer>