Date: Fri, 10 Mar 2006 10:32:06 -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: <4411C626.8030702@savvis.net> In-Reply-To: <1141980206.657073.302.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> <44107C19.6050302@savvis.net> <1141980206.657073.302.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Iain Hibbert wrote: > 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 :) again, because they are different protocols, and have different properties. >>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. ok, i think, i understand what you are saying now. it seems like you are objecting to the fact that all sockaddr_* in bluetooth domain have family set AF_BLUETOOTH. i do not see this as a big problem. when socket(2) is called you have to specify "protocol" parameter (i'm talking about freebsd bluetooth sockets here). since bind(2), connect(2) etc. accept struct sockaddr pointer you have to cast pointer anyway, and, because you know which protocol you are dealing with, you can cast it to the correct struct sockaddr_X pointer anyway. this is somewhat similar to AF_INET family where you can have IP, ICMP, TCP, UDP, etc. protocols. all within the same AF_INET family/domain. in other words: AF_BLUETOOTH - defines domain, BLUETOOTH_PROTO_X defines protocol and tells which struct sockaddr_X must be used. for the reasons above, i decided to not introduce separate AF_BLUETOOTH_X families for different protocols. > 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. i'm not really sure i understand what are you talking about here. to me, each socket have to have sockaddr_x anyway and you have to fill it with correct values. please consider another example: lets say another rfcomm-like protocol is defined and added to the bluetooth stack. if you have flat sockaddr_bt you might need to add some fields to sockaddr_bt structure to implement new protocol. this will likely to break binary compatibility. if you have separate sockaddr_bt_x per protocol - you are safe. > 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. yes, that was the reason (at least for me) to keep initialization procedure in user space. it seems like more flexible solution to me. i thinking about manufacturer specific initialization sequences. > I am going to see what the netbsd opinion on this is, I can't claim to be > an expert in these matters, heh.. ok >>>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. have you tried with, say, with mobile phone. have you tried to advertise rfcomm-based service on different psm? did the phone made connection to the right psm to open rfcomm session? thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4411C626.8030702>