Date: Thu, 09 Mar 2006 11:03:53 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: Iain Hibbert <plunky@rya-online.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: whitespace Message-ID: <44107C19.6050302@savvis.net> In-Reply-To: <1141807931.899207.8150.nullmailer@galant.ukfsn.org> 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> <1141807931.899207.8150.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Iain Hibbert wrote:
> 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?
node name size was bumped sometime ago to 32. that is why i put 32 in
there.
> 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 :)
well, i still do not understand why you insist on flat sockaddr_bt
structure. sockaddr_* structures exist for a reason. we do not lump
together, say, sockaddr_in and sockaddr_ipx. those are different
protocols are the fact that both can be run over ethernet does not
require us to lump them.
the same (in some sense) applies to bluetooth. sure, l2cap, rfcomm etc.
run over acl link. sure, they share some common properties (i.e.
bd_addr). the point is that those are different protocols. it makes
sense (to me) to keep them separate.
so, imo, unions would work. another way is to create
struct sockaddr_bt
{
uint8_t len;
sa_family_t family;
uint8 addr[0]; /* variable size of len-sizeof(len)-sizeof(family) */
}
then have bunch of sockaddr_bt_* structures that would go into addr[]
field. similar to struct sockaddr, struct sockaddr_in etc.
> 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.
i we can get source compatibility that would be enough for me. binary
compatibility is ideal.
>>>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?
well, not really, imo. the first element is protocol uuid, not psm. i
think, you would have to add protocol specific parameter to l2cap
protocol that tells which psm to use to get access to the higher level
protocol (i.e. rfcomm). in other words
Protocol Descriptor List:
L2CAP (0x0100)
Protocol specific parameter #1: u/int16 0x1007 -- l2cap psm for rfcomm
RFCOMM (0x0003)
Protocol specific parameter #1: u/int8/bool 1 -- rfcomm channel
i have never seen anything like this, and i'm not sure if this will even
work with other stacks.
> 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 :)
i think if someone wants to use custom service they better off running
it over l2cap. if rfcomm is required, then there are 32 available
channels. also, it is possible to write rfcomm implementation completely
in userspace and it on any psm.
thanks,
max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44107C19.6050302>