[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 06 Jun 2007 13:39:16 +0200
From: Patrick McHardy <kaber@...sh.net>
To: Urs Thuermann <urs@...ogud.escape.de>
CC: Oliver Hartkopp <socketcan@...tkopp.net>,
David Miller <davem@...emloft.net>,
Thomas Gleixner <tglx@...utronix.de>,
Oliver Hartkopp <oliver.hartkopp@...kswagen.de>,
netdev@...r.kernel.org
Subject: Re: [patch 5/7] CAN: Add virtual CAN netdevice driver
Urs Thuermann wrote:
> Patrick McHardy <kaber@...sh.net> writes:
>
>>I don't get why you can't directly check the socket option on the
>>TX path.
>
>
> We have several types of sockets in the PF_CAN family, two of which
> are GPL'ed and which are in the patch series. These are CAN_RAW and
> CAN_BCM. The protocol implementations use can_send() in af_can.c to
> send a CAN frame and indicate to can_send() in an int argument,
> whether this frame should be looped back. Only the raw protocol has a
> socket option (setsockopt(2)) in struct raw_sock for this, bcm always
> sets this to 1 to have the frame looped back. There is no option in
> struct bcm_sock for this. In can_send() and in the driver we don't
> know what type of socket skb->sk points to and can't check that
> option. Changing this would mean we have to add such an option in the
> same position in all CAN socket types and set it to fixed values in
> some of them (e.g. to 1 for bcm). While it's doable, I wouldn't like
> that very much.
>
> Is there anything that prevents can_send() from using skb->pkt_type to
> pass the loopback flag down to the driver?
No, that should be fine, in fact it should set it anyway even if you
can't use it for this purpose.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists