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
--
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
