Date: Fri, 10 Mar 2006 08:43:26 +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: <1141980206.657073.302.nullmailer@galant.ukfsn.org> In-Reply-To: <44107C19.6050302@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> <1141807931.899207.8150.nullmailer@galant.ukfsn.org> <44107C19.6050302@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 9 Mar 2006, Maksim Yevmenkin wrote: > Iain Hibbert wrote: > well, i still do not understand why you insist on flat sockaddr_bt structure. Well, I still dont understand why it was created differently :) > 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. Ok, we dont have sockaddr_ipx and I'm not sure what that is, but if you look at sockaddr_in and sockaddr_in6 they are different for a reason, because the addresses are different. But now, because they are different, they have a different sa_family type (AF_INET and AF_INET6) and when you look at the sockaddr you can tell which it is. It just makes no sense to me to have different structures with the same tag and there be no way to tell the difference. In my stack when you open an RFCOMM socket, it uses the sockaddr to open the L2CAP channel. When incoming connections are detected, the sockaddr is only created once, it just gets passed up. Actually, I can see a partial reason to have the HCI_RAW socket address different, in that bluetooth devices have no address available until they are up and running. I handled the device initiation in kernel and didnt notice that until recently. I am going to see what the netbsd opinion on this is, I can't claim to be an expert in these matters, heh.. > > 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. Ah, thanks.. I see what they are saying now. I misinterpreted it because they have used the PSM as UUID. The example actually is: ((L2CAP, PSM=0x1001), (RFCOMM, CN=1), (Obex), (vCal)) ((L2CAP, PSM=0x1002), (RFCOMM, CN=1), (Obex), (Other)) which is as you said, but imho that should just work. Actually, to make that work was quite simple I think all I did in effect was to change the session lookup routine to ignore different psm values, and also set the psm to L2CAP_PSM_RFCOMM if it was unset. iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1141980206.657073.302.nullmailer>