On Fri, Feb 19, 2010 at 12:08 AM, Ville Tervo <ville.tervo@xxxxxxxxx> wrote: > Hi Nick > >>> And even if we would be going for a setsockopt(), that would be blocking >>> and then again pretty much pointless API. The sockaddr is most logical >>> thing that fits into what we wanna achieve. Disallow/allow certain >>> packet types and essentially force SCO over eSCO. >> >> Ok seems like there is agreement on using struct sockaddr_sco for >> sco_pkt_type. >> >> A more controversial question is whether to follow the SIG convention >> of reversing the logic on the EDR bits in the packet type mask (1 >> means do *not* use this packet for the EDR bits), or to use consistent >> logic for each bit (1 always means *allow* this packet type) for >> packet selection in scokaddr_sco.sco_pkt_type. >> >> The original patch I posted followed the SIG convention. However after >> more thinking I am leaning towards using consistent logic for each >> bit. 1 will always mean 'allow this packet'. My rationale is that the >> most common use for sco_pkt_type will be to request only SCO packet >> types allowed. If however the SIG adds more reverse logic packet >> types, and we follow the SIG convention, then old userspace code that >> just requested the SCO packet types will now end up with the new >> packet types as well. So I think it is best to avoid this situation >> and for 1 to always mean 'allow this packet' in >> sockaddr_sco.sco_pkt_type. >> >> Attached is a new patch with the consistent bit logic. >> >> Comments? > > In order to keep backwards compatibility 1 should mean "don't allow this > packet type" for all packets. Other wise old application with new kernel > would not allow any packet types. The current patch achieves this backwards compatibility by assuming that all packet types are allowed if the old sockaddr_sco struct is used (it checks the size), or if sco_pkt_type is 0. Nick -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
