netdev - Re: [PATCH 7/7] CAN: Add documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Sep 2007 15:57:18 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Urs Thuermann <urs@...ogud.escape.de>
Cc:	Thomas Gleixner <tglx@...utronix.de>, netdev@...r.kernel.org,
	David Miller <davem@...emloft.net>,
	Patrick McHardy <kaber@...sh.net>,
	Oliver Hartkopp <oliver@...tkopp.net>,
	Oliver Hartkopp <oliver.hartkopp@...kswagen.de>
Subject: Re: [PATCH 7/7] CAN: Add documentation

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

> Thomas Gleixner <tglx@...utronix.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.


> +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.

> +  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

> +  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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html