Re: [PATCH] Bluetooth: Allow SCO/eSCO packet type selection for outgoing SCO connections.

[Ville Tervo <ville.tervo@nokia.com>]

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.

-- 
Ville