Hi Gustavo,
> RFCOMM needs a proper priority mechanism inside itself and not try to use
> l2cap priority to fix its own problem.
<snip>
> static void rfcomm_make_uih(struct sk_buff *skb, u8 addr)
> @@ -1786,8 +1776,15 @@ static inline int rfcomm_process_tx(struct rfcomm_dlc *d)
> return skb_queue_len(&d->tx_queue);
>
> while (d->tx_credits && (skb = skb_dequeue(&d->tx_queue))) {
> - err = rfcomm_send_frame(d->session, skb->data, skb->len,
> - skb->priority);
> + struct socket *sock = d->session->sock;
> + struct sock *sk = sock->sk;
> +
> + if (sk->sk_priority != skb->priority) {
> + lock_sock(sk);
> + sk->sk_priority = skb->priority;
> + release_sock(sk);
> + }
> + err = rfcomm_send_frame(d->session, skb->data, skb->len);
> if (err < 0) {
> skb_queue_head(&d->tx_queue, skb);
> break;
coming to think about this, we might not even bother setting the
sk->sk_priority at all here. Lets just forget about RFCOMM.
Regards
Marcel
--
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
