Date: Tue, 31 Jan 2006 22:33:15 +0000 (GMT) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: bluetooth compatibility Message-ID: <1138746795.375218.15473.nullmailer@galant.ukfsn.org> In-Reply-To: <43DFBF8A.7040606@savvis.net> References: <1134598760.901248.1323.nullmailer@galant.ukfsn.org> <43A0AB9E.7060808@savvis.net> <1138708994.303189.24314.nullmailer@galant.ukfsn.org> <43DFAACD.5040802@savvis.net> <1138734561.599404.4457.nullmailer@galant.ukfsn.org> <43DFBF8A.7040606@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 31 Jan 2006, Maksim Yevmenkin wrote: > yes, i was thinking about moving most of the includes into include/bluetooth > or something like that. the naming convention is an artifact of very early > stage of development (when the code was developed outside of the freebsd > source tree) in a way its not that important - the values are the same and basic HCI definitions can be represented in a compatibility file (I think you have one such for BlueZ?) Well I have include files in netbt/ which makes sense for NetBSD (also OpenBSD) not sure though that FreeBSD (and DragonFly BSD?) have the same directory structure any more? In fact I noticed that you include all the other files from within <bluetooth.h> anyway which I may end up doing - that way user programs only need to include the one file and less changes need to be made when porting software. > > The biggest choice I made that intentionaly breaks compatibility is that I > > chose to have bluetooth address family socket address consistent through > > the family (ie a single struct sockaddr_bt for all AF_BLUETOOTH sockets) - > > this means so far that HCI sockets use the bdaddr instead of device name > > and that L2CAP sockets must set the PSM via setsockopt() > > may i ask why did you make this decision? Well I considered that the socket address is identified by the family, therefore it should have the same type of address throughout at least. You can look at the sa_family type and know how to interpret it. Also, addresses can be passed up and down the stack layers without problems (dont know how useful that will be) regarding the PSM, when I got to it I thought that possibly it could be in the sockaddr_bt (and just be ignored for HCI) as you may need to set an PSM for protocols other than L2CAP that you might access through another socket type. Actually this is something that is simple to change in the future so I just left it for now regards, iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1138746795.375218.15473.nullmailer>