On Thu, Sep 23, 2010 at 02:12:25PM +0200, Oliver Hartkopp wrote: > On 22.09.2010 16:53, Kurt Van Dijck wrote: > > On Wed, Sep 22, 2010 at 04:16:50PM +0200, [email protected] wrote: > > >>> For self-received messages, the originating socket (sk_buff->sk) is > >>> set. I think it's only accessible in kernel. Using this would IMO > >>> avoid adding code in difficult places, and limit such feature to > >>> adding code in easy places. > > More exactly, self-received messages originating from a socket have > > this member set. It is possible from kernelspace to inject CAN messages > > without any socket, but I guess that's beyond scope. > > But if we would use skb->sk to distinguish internal from external originated > traffic, we need to make sure that internally generated traffic also sets > skb->sk correctly. Yep.
If I understand correctly, this requirement would only be true for a certain subset of CANopen processes. If, a local generated message would originate from outside the CANopen subset, it would mean that the CANopen process should evaluate it as 'external' anyway. Is that true? In that case, only the transmission paths involved in the CANopen processes need to verify they set sk_buff->sk. > To stick on the code in candump.c the field msg.msg_flags could contain a bit > MSG_DONTROUTE after recvmsg(), whenever the CAN frames are not routed inside > the system. > > In raw.c this (untested) patch could set the flag according to an available sk > reference. When we have an 'alien' from outside our system the bit would be > set. > > So far MSG_DONTROUTE is only used in sendmsg() - if this tiny patch fits your > needs we need to see, if it's ok for the netdev guys to use this flag in the > receive path for CAN also. IMHO, the name is contra-intuitive. Alternatives? > Kurt _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
