Urs Thuermann wrote: > Patrick McHardy <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
