On 17 Sep 2007 22:49:34 +0200 Urs Thuermann wrote:

quoted text
> Thomas Gleixner <tglx@linutronix.de> writes:
> 
> > Please do, having the patch in mail makes it easier to review and to
> > comment.
> 
> OK, here it is:

Just a few more minor changes...  Thanks again.


quoted text
> +3. Socket CAN concept
> +---------------------
> +
> +  As described in chapter 2 it is the main goal of Socket CAN to
> +  provide a socket interface to user space applications which builds
> +  upon the Linux networklayer. In contrast to the commonly known

                    network layer.

quoted text
> +  TCP/IP and ethernet networking, the CAN bus is a broadcast-only(!)
> +  medium that has no MAC-layer addressing like ethernet. The CAN-identifier
> +  (can_id) is used for arbitration on the CAN-bus. Therefore the CAN-IDs
> +  have to be chosen uniquely on the bus. When designing a CAN-ECU
> +  network the CAN-IDs are mapped to be sent by a specific ECU.
> +  For this reason a CAN-ID can be treated best as a kind of source address.
> +
> +  3.2 loopback
> +
> +  As known from other networking concepts the data exchanging
> +  applications may run on the same or different nodes without any
> +  change (except for the according addressing information):
> +
> +         ___   ___   ___                   _______   ___
> +        | _ | | _ | | _ |                 | _   _ | | _ |
> +        ||A|| ||B|| ||C||                 ||A| |B|| ||C||
> +        |___| |___| |___|                 |_______| |___|
> +          |     |     |                       |       |
> +        -----------------(1)- CAN bus -(2)---------------
> +
> +  To ensure that application A receives the same information in the
> +  example (2) as it would receive in example (1) there is need for
> +  some kind of local loopback on the appropriate node.
> +
> +  The Linux network devices (by default) just can handle the
> +  transmission and reception of media dependent frames. Due to the
> +  arbritration on the CAN bus the transmission of a low prio CAN-ID
> +  may be delayed by the recepition of a high prio CAN frame. To

                           reception

quoted text
> +  reflect the correct* traffic on the node the loopback of the sent
> +  data has to be performed right after a successful transmission. If
> +  the CAN network interface is not capable of performing the loopback for
> +  some reason the SocketCAN core can do this task as a fallback solution.
> +  See chapter 6.2 for details (recommended).
> +
> +  The loopback functionality is enabled by default to reflect standard
> +  networking behaviour for CAN applications. Due to some requests from
> +  the RT-SocketCAN group the loopback optionally may be disabled for each
> +  separate socket. See sockopts from the CAN RAW sockets in chapter 4.1.
> +
> +  * = you really like to have this when you're running analyser tools
> +      like 'candump' or 'cansniffer' on the (same) node.
> +

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html