On 23.09.2010 14:47, Kurt Van Dijck wrote: > On Thu, Sep 23, 2010 at 02:12:25PM +0200, Oliver Hartkopp wrote: >> On 22.09.2010 16:53, Kurt Van Dijck wrote:
>> 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. That would mean a distinction of CAN applications and not inside/outside traffic distinction. To realize this Vladislav could use the SO_MARK socketoption to define a "CANopen" specific identifier on *all* sockets that send CANopen datagramms. This identifier could be passed back via cmsg (using recvmsg) - but AFAICS there's no automatic SO_MARK control message delivery to the userspace in the socketlayer functions. >> 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? This is a simple idea to implement a potential commonly unused feature :-) And it only addresses inside/outside traffic distinction. @Vladislav: Did you think about implementing some of your CANopen functionality inside the Kernel? Especially for getting your specific information about CAN frames and to ensure high-res timer handling, as done in bcm.c or isotp.c ?!? Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
