Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy <kaber@trash.net>]

Urs Thuermann wrote:
> Patrick McHardy <kaber@trash.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.