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

[Nick Pelly <npelly@google.com>]

On Fri, Feb 19, 2010 at 12:08 AM, Ville Tervo <ville.tervo@nokia.com> 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