[PATCH 0/7] CAN: Add new PF_CAN protocol family, try #8

[PATCH 0/7] CAN: Add new PF_CAN protocol family, try #8

[Urs Thuermann]

Hello Dave, hello Patrick,

this is the eigth post of the patch series that adds the PF_CAN
protocol family for the Controller Area Network.

Since our last post we have changed the following:

* Some changes in debug code, following suggestions from Joe Perches:
  - Remove dynamically allocated buffer for debug output.
  - Use kernel functions for hexdumps.
  - Don't interpret printf-style %-sequences in can_debug_cframe().
  - Specify the fixed argument "fmt" to DBG() macro and use
    GCC ## mechanism to remove , when args is empty.
* Removed CAN_RAW_USER and CAN_BCM_USER Kconfig options following a
  suggestion from Patrick.
* Prevent overflow in statistics calculation.
* Minor optimization.

The changes in try #7 were:

* Changes suggested by Patrick:
  - protect proto_tab[] by a lock.
  - add _rcu to some hlist traversals.
  - use printk_ratelimit() for module autoload failures.
  - make can_proto_unregister() and can_rx_unregister() return void.
  - use return value of can_proto_register() and can_rx_register()
    (this also removed a flaw in behavior of raw_bind() and raw_setsockopt()
     in case of failure to can_rx_register() their filters).
  - call kzalloc() with GFP_KERNEL in case NETDEV_REGISTER.
  - use round_jiffies() to calculate expiration times.
  - make some variables static and/or __read_mostly.
  - in can_create() check for net namespace before auto loading modules.
  - add build time check for struct sizes.
  - use skb_share_chack() in vcan.
  - fixed some comments.
* Typos in documentation as pointed out by Randy Dunlap and Bill Fink.

The changes in try #6 were:

* Update code to work with namespaces in net-2.6.24.
* Remove SET_MODULE_OWNER() from vcan.

The changes in try #5 were:

* Remove slab destructor from calls to kmem_cache_alloc().
* Add comments about types defined in can.h.
* Update comment on vcan loopback module parameter.
* Fix typo in documentation.

The changes in try #4 were:

* Change vcan network driver to use the new RTNL API, as suggested by
  Patrick.
* Revert our change to use skb->iif instead of skb->cb.  After
  discussion with Patrick and Jamal it turned out, our first
  implementation was correct.
* Use skb_tail_pointer() instead of skb->tail directly.
* Coding style changes to satisfy linux/scripts/checkpatch.pl.
* Minor changes for 64-bit-cleanliness.
* Minor cleanup of #include's

The changes in try #3 were:

* Use sbk->sk and skb->pkt_type instead of skb->cb to pass loopback
  flags and originating socket down to the driver and back to the
  receiving socket.  Thanks to Patrick McHardy for pointing out our
  wrong use of sbk->cb.
* Use skb->iif instead of skb->cb to pass receiving interface from
  raw_rcv() and bcm_rcv() up to raw_recvmsg() and bcm_recvmsg().
* Set skb->protocol when sending CAN frames to netdevices.
* Removed struct raw_opt and struct bcm_opt and integrated these
  directly into struct raw_sock and bcm_sock resp., like most other
  proto implementations do.
* We have found and fixed race conditions between raw_bind(),
  raw_{set,get}sockopt() and raw_notifier().  This resulted in
  - complete removal of our own notifier list infrastructure in
    af_can.c.  raw.c and bcm.c now use normal netdevice notifiers.
  - removal of ro->lock spinlock.  We use lock_sock(sk) now.
  - changed deletion of dev_rcv_lists, which are now marked for
    deletion in the netdevice notifier in af_can.c and are actually
    deleted when all entries have been deleted using can_rx_unregister().
* Follow changes in 2.6.22 (e.g. ktime_t timestamps in skb).
* Removed obsolete code from vcan.c, as pointed out by Stephen Hemminger.

The changes in try #2 were:

* reduced RCU callback overhead when deleting receiver lists (thx to
  feedback from Paul E. McKenney).
* eliminated some code duplication in net/can/proc.c.
* renamed slock-29 and sk_lock-29 to slock-AF_CAN and sk_lock-AF_CAN in
  net/core/sock.c
* added entry for can.txt in Documentation/networking/00-INDEX
* added error frame definitions in include/linux/can/error.h, which are to
  be used by CAN network drivers.


This patch series applies against net-2.6.24 and is derived from Subversion
revision r493 of http://svn.berlios.de/svnroot/repos/socketcan.
It can be found in the directory
http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/<version>.

Thanks very much for your work!

Best regards,

Urs Thuermann
Oliver Hartkopp
--

[PATCH 1/7] CAN: Allocate protocol numbers for PF_CAN

[Urs Thuermann]

[-- Attachment #1: 01-can-proto-numbers.diff --]
[-- Type: text/plain, Size: 4739 bytes --]

This patch adds a protocol/address family number, ARP hardware type,
ethernet packet type, and a line discipline number for the SocketCAN
implementation.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 include/linux/if_arp.h   |    1 +
 include/linux/if_ether.h |    1 +
 include/linux/socket.h   |    2 ++
 include/linux/tty.h      |    3 ++-
 net/core/sock.c          |    4 ++--
 5 files changed, 8 insertions(+), 3 deletions(-)

Index: net-2.6.24/include/linux/if_arp.h
===================================================================
--- net-2.6.24.orig/include/linux/if_arp.h	2007-09-20 18:48:21.000000000 +0200
+++ net-2.6.24/include/linux/if_arp.h	2007-09-20 18:48:57.000000000 +0200
@@ -52,6 +52,7 @@
 #define ARPHRD_ROSE	270
 #define ARPHRD_X25	271		/* CCITT X.25			*/
 #define ARPHRD_HWX25	272		/* Boards with X.25 in firmware	*/
+#define ARPHRD_CAN	280		/* Controller Area Network      */
 #define ARPHRD_PPP	512
 #define ARPHRD_CISCO	513		/* Cisco HDLC	 		*/
 #define ARPHRD_HDLC	ARPHRD_CISCO
Index: net-2.6.24/include/linux/if_ether.h
===================================================================
--- net-2.6.24.orig/include/linux/if_ether.h	2007-09-20 18:48:21.000000000 +0200
+++ net-2.6.24/include/linux/if_ether.h	2007-09-20 18:48:57.000000000 +0200
@@ -90,6 +90,7 @@
 #define ETH_P_WAN_PPP   0x0007          /* Dummy type for WAN PPP frames*/
 #define ETH_P_PPP_MP    0x0008          /* Dummy type for PPP MP frames */
 #define ETH_P_LOCALTALK 0x0009		/* Localtalk pseudo type 	*/
+#define ETH_P_CAN	0x000C		/* Controller Area Network      */
 #define ETH_P_PPPTALK	0x0010		/* Dummy type for Atalk over PPP*/
 #define ETH_P_TR_802_2	0x0011		/* 802.2 frames 		*/
 #define ETH_P_MOBITEX	0x0015		/* Mobitex (kaz@cafe.net)	*/
Index: net-2.6.24/include/linux/socket.h
===================================================================
--- net-2.6.24.orig/include/linux/socket.h	2007-09-20 18:48:21.000000000 +0200
+++ net-2.6.24/include/linux/socket.h	2007-09-20 18:48:57.000000000 +0200
@@ -185,6 +185,7 @@
 #define AF_PPPOX	24	/* PPPoX sockets		*/
 #define AF_WANPIPE	25	/* Wanpipe API Sockets */
 #define AF_LLC		26	/* Linux LLC			*/
+#define AF_CAN		29	/* Controller Area Network      */
 #define AF_TIPC		30	/* TIPC sockets			*/
 #define AF_BLUETOOTH	31	/* Bluetooth sockets 		*/
 #define AF_IUCV		32	/* IUCV sockets			*/
@@ -220,6 +221,7 @@
 #define PF_PPPOX	AF_PPPOX
 #define PF_WANPIPE	AF_WANPIPE
 #define PF_LLC		AF_LLC
+#define PF_CAN		AF_CAN
 #define PF_TIPC		AF_TIPC
 #define PF_BLUETOOTH	AF_BLUETOOTH
 #define PF_IUCV		AF_IUCV
Index: net-2.6.24/include/linux/tty.h
===================================================================
--- net-2.6.24.orig/include/linux/tty.h	2007-09-20 18:48:21.000000000 +0200
+++ net-2.6.24/include/linux/tty.h	2007-09-20 18:48:57.000000000 +0200
@@ -24,7 +24,7 @@
 #define NR_PTYS	CONFIG_LEGACY_PTY_COUNT   /* Number of legacy ptys */
 #define NR_UNIX98_PTY_DEFAULT	4096      /* Default maximum for Unix98 ptys */
 #define NR_UNIX98_PTY_MAX	(1 << MINORBITS) /* Absolute limit */
-#define NR_LDISCS		17
+#define NR_LDISCS		18
 
 /* line disciplines */
 #define N_TTY		0
@@ -45,6 +45,7 @@
 #define N_SYNC_PPP	14	/* synchronous PPP */
 #define N_HCI		15	/* Bluetooth HCI UART */
 #define N_GIGASET_M101	16	/* Siemens Gigaset M101 serial DECT adapter */
+#define N_SLCAN		17	/* Serial / USB serial CAN Adaptors */
 
 /*
  * This character is the same as _POSIX_VDISABLE: it cannot be used as
Index: net-2.6.24/net/core/sock.c
===================================================================
--- net-2.6.24.orig/net/core/sock.c	2007-09-20 18:48:21.000000000 +0200
+++ net-2.6.24/net/core/sock.c	2007-09-20 18:48:57.000000000 +0200
@@ -154,7 +154,7 @@
   "sk_lock-AF_ASH"   , "sk_lock-AF_ECONET"   , "sk_lock-AF_ATMSVC"   ,
   "sk_lock-21"       , "sk_lock-AF_SNA"      , "sk_lock-AF_IRDA"     ,
   "sk_lock-AF_PPPOX" , "sk_lock-AF_WANPIPE"  , "sk_lock-AF_LLC"      ,
-  "sk_lock-27"       , "sk_lock-28"          , "sk_lock-29"          ,
+  "sk_lock-27"       , "sk_lock-28"          , "sk_lock-AF_CAN"      ,
   "sk_lock-AF_TIPC"  , "sk_lock-AF_BLUETOOTH", "sk_lock-IUCV"        ,
   "sk_lock-AF_RXRPC" , "sk_lock-AF_MAX"
 };
@@ -168,7 +168,7 @@
   "slock-AF_ASH"   , "slock-AF_ECONET"   , "slock-AF_ATMSVC"   ,
   "slock-21"       , "slock-AF_SNA"      , "slock-AF_IRDA"     ,
   "slock-AF_PPPOX" , "slock-AF_WANPIPE"  , "slock-AF_LLC"      ,
-  "slock-27"       , "slock-28"          , "slock-29"          ,
+  "slock-27"       , "slock-28"          , "slock-AF_CAN"      ,
   "slock-AF_TIPC"  , "slock-AF_BLUETOOTH", "slock-AF_IUCV"     ,
   "slock-AF_RXRPC" , "slock-AF_MAX"
 };

--

[PATCH 2/7] CAN: Add PF_CAN core module

[Urs Thuermann]

[-- Attachment #1: 02-can-core.diff --]
[-- Type: text/plain, Size: 60373 bytes --]

This patch adds the CAN core functionality but no protocols or drivers.
No protocol implementations are included here.  They come as separate
patches.  Protocol numbers are already in include/linux/can.h.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 include/linux/can.h       |  111 +++++
 include/linux/can/core.h  |   77 +++
 include/linux/can/error.h |   93 ++++
 net/Kconfig               |    1 
 net/Makefile              |    1 
 net/can/Kconfig           |   25 +
 net/can/Makefile          |    6 
 net/can/af_can.c          |  973 ++++++++++++++++++++++++++++++++++++++++++++++
 net/can/af_can.h          |  121 +++++
 net/can/proc.c            |  533 +++++++++++++++++++++++++
 10 files changed, 1941 insertions(+)

Index: net-2.6.24/include/linux/can.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/include/linux/can.h	2007-09-25 13:14:46.000000000 +0200
@@ -0,0 +1,111 @@
+/*
+ * linux/can.h
+ *
+ * Definitions for CAN network layer (socket addr / CAN frame / CAN filter)
+ *
+ * Authors: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
+ *          Urs Thuermann   <urs.thuermann@volkswagen.de>
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#ifndef CAN_H
+#define CAN_H
+
+#include <linux/types.h>
+#include <linux/socket.h>
+
+/* controller area network (CAN) kernel definitions */
+
+/* special address description flags for the CAN_ID */
+#define CAN_EFF_FLAG 0x80000000U /* EFF/SFF is set in the MSB */
+#define CAN_RTR_FLAG 0x40000000U /* remote transmission request */
+#define CAN_ERR_FLAG 0x20000000U /* error frame */
+
+/* valid bits in CAN ID for frame formats */
+#define CAN_SFF_MASK 0x000007FFU /* standard frame format (SFF) */
+#define CAN_EFF_MASK 0x1FFFFFFFU /* extended frame format (EFF) */
+#define CAN_ERR_MASK 0x1FFFFFFFU /* omit EFF, RTR, ERR flags */
+
+/*
+ * Controller Area Network Identifier structure
+ *
+ * bit 0-28	: CAN identifier (11/29 bit)
+ * bit 29	: error frame flag (0 = data frame, 1 = error frame)
+ * bit 30	: remote transmission request flag (1 = rtr frame)
+ * bit 31	: frame format flag (0 = standard 11 bit, 1 = extended 29 bit)
+ */
+typedef __u32 canid_t;
+
+/*
+ * Controller Area Network Error Frame Mask structure
+ *
+ * bit 0-28	: error class mask (see include/linux/can/error.h)
+ * bit 29-31	: set to zero
+ */
+typedef __u32 can_err_mask_t;
+
+/**
+ * struct can_frame - basic CAN frame structure
+ * @can_id:  the CAN ID of the frame and CAN_*_FLAG flags, see above.
+ * @can_dlc: the data length field of the CAN frame
+ * @data:    the CAN frame payload.
+ */
+struct can_frame {
+	canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
+	__u8    can_dlc; /* data length code: 0 .. 8 */
+	__u8    data[8] __attribute__((aligned(8)));
+};
+
+/* particular protocols of the protocol family PF_CAN */
+#define CAN_RAW		1 /* RAW sockets */
+#define CAN_BCM		2 /* Broadcast Manager */
+#define CAN_TP16	3 /* VAG Transport Protocol v1.6 */
+#define CAN_TP20	4 /* VAG Transport Protocol v2.0 */
+#define CAN_MCNET	5 /* Bosch MCNet */
+#define CAN_ISOTP	6 /* ISO 15765-2 Transport Protocol */
+#define CAN_NPROTO	7
+
+#define SOL_CAN_BASE 100
+
+/**
+ * struct sockaddr_can - the sockaddr structure for CAN sockets
+ * @can_family:  address family number AF_CAN.
+ * @can_ifindex: CAN network interface index.
+ * @can_addr:    transport protocol specific address, mostly CAN IDs.
+ */
+struct sockaddr_can {
+	sa_family_t can_family;
+	int         can_ifindex;
+	union {
+		struct { canid_t rx_id, tx_id; } tp16;
+		struct { canid_t rx_id, tx_id; } tp20;
+		struct { canid_t rx_id, tx_id; } mcnet;
+		struct { canid_t rx_id, tx_id; } isotp;
+	} can_addr;
+};
+
+/**
+ * struct can_filter - CAN ID based filter in can_register().
+ * @can_id:   relevant bits of CAN ID which are not masked out.
+ * @can_mask: CAN mask (see description)
+ *
+ * Description:
+ * A filter matches, when
+ *
+ *          <received_can_id> & mask == can_id & mask
+ *
+ * The filter can be inverted (CAN_INV_FILTER bit set in can_id) or it can
+ * filter for error frames (CAN_ERR_FLAG bit set in mask).
+ */
+struct can_filter {
+	canid_t can_id;
+	canid_t can_mask;
+};
+
+#define CAN_INV_FILTER 0x20000000U /* to be set in can_filter.can_id */
+
+#endif /* CAN_H */
Index: net-2.6.24/include/linux/can/core.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/include/linux/can/core.h	2007-09-25 13:22:22.000000000 +0200
@@ -0,0 +1,77 @@
+/*
+ * linux/can/core.h
+ *
+ * Protoypes and definitions for CAN protocol modules using the PF_CAN core
+ *
+ * Authors: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
+ *          Urs Thuermann   <urs.thuermann@volkswagen.de>
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#ifndef CAN_CORE_H
+#define CAN_CORE_H
+
+#include <linux/can.h>
+#include <linux/skbuff.h>
+#include <linux/netdevice.h>
+
+#define CAN_VERSION "20070920"
+
+/* increment this number each time you change some user-space interface */
+#define CAN_ABI_VERSION "8"
+
+#define CAN_VERSION_STRING "rev " CAN_VERSION " abi " CAN_ABI_VERSION
+
+#define DNAME(dev) ((dev) ? (dev)->name : "any")
+
+/**
+ * struct can_proto - CAN protocol structure
+ * @type:       type argument in socket() syscall, e.g. SOCK_DGRAM.
+ * @protocol:   protocol number in socket() syscall.
+ * @capability: capability needed to open the socket, or -1 for no restriction.
+ * @ops:        pointer to struct proto_ops for sock->ops.
+ * @prot:       pointer to struct proto structure.
+ */
+struct can_proto {
+	int              type;
+	int              protocol;
+	int              capability;
+	struct proto_ops *ops;
+	struct proto     *prot;
+};
+
+/* function prototypes for the CAN networklayer core (af_can.c) */
+
+extern int  can_proto_register(struct can_proto *cp);
+extern void can_proto_unregister(struct can_proto *cp);
+
+extern int  can_rx_register(struct net_device *dev, canid_t can_id,
+			    canid_t mask,
+			    void (*func)(struct sk_buff *, void *),
+			    void *data, char *ident);
+
+extern void can_rx_unregister(struct net_device *dev, canid_t can_id,
+			      canid_t mask,
+			      void (*func)(struct sk_buff *, void *),
+			      void *data);
+
+extern int can_send(struct sk_buff *skb, int loop);
+
+#ifdef CONFIG_CAN_DEBUG_CORE
+extern void can_debug_skb(struct sk_buff *skb);
+extern void can_debug_cframe(const char *msg, struct can_frame *cframe);
+#define DBG(fmt, args...)  (debug & 1 ? printk(KERN_DEBUG "can-" IDENT \
+					" %s: " fmt, __func__, ##args) : 0)
+#define DBG_FRAME(fmt, cf) (debug & 2 ? can_debug_cframe(fmt, cf) : 0)
+#define DBG_SKB(skb)       (debug & 4 ? can_debug_skb(skb) : 0)
+#else
+#define DBG(fmt, args...)
+#define DBG_FRAME(fmt, cf)
+#define DBG_SKB(skb)
+#endif
+
+#endif /* CAN_CORE_H */
Index: net-2.6.24/net/Kconfig
===================================================================
--- net-2.6.24.orig/net/Kconfig	2007-09-24 17:53:08.000000000 +0200
+++ net-2.6.24/net/Kconfig	2007-09-25 13:14:46.000000000 +0200
@@ -210,6 +210,7 @@
 endmenu
 
 source "net/ax25/Kconfig"
+source "net/can/Kconfig"
 source "net/irda/Kconfig"
 source "net/bluetooth/Kconfig"
 source "net/rxrpc/Kconfig"
Index: net-2.6.24/net/Makefile
===================================================================
--- net-2.6.24.orig/net/Makefile	2007-09-24 17:53:08.000000000 +0200
+++ net-2.6.24/net/Makefile	2007-09-25 13:14:46.000000000 +0200
@@ -34,6 +34,7 @@
 obj-$(CONFIG_NETROM)		+= netrom/
 obj-$(CONFIG_ROSE)		+= rose/
 obj-$(CONFIG_AX25)		+= ax25/
+obj-$(CONFIG_CAN)		+= can/
 obj-$(CONFIG_IRDA)		+= irda/
 obj-$(CONFIG_BT)		+= bluetooth/
 obj-$(CONFIG_SUNRPC)		+= sunrpc/
Index: net-2.6.24/net/can/Kconfig
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/net/can/Kconfig	2007-09-25 13:14:46.000000000 +0200
@@ -0,0 +1,25 @@
+#
+# Controller Area Network (CAN) network layer core configuration
+#
+
+menuconfig CAN
+	depends on NET
+	tristate "CAN bus subsystem support"
+	---help---
+	  Controller Area Network (CAN) is a slow (up to 1Mbit/s) serial
+	  communications protocol, which was developed by Bosch at
+	  1991 mainly for automotive, but now widely used in marine
+	  (NMEA2000), industrial and medical applications.
+	  More information on the CAN network protocol family PF_CAN
+	  is contained in <Documentation/networking/can.txt>.
+
+	  If you want CAN support, you should say Y here and also to the
+	  specific driver for your controller(s) below.
+
+config CAN_DEBUG_CORE
+	bool "CAN Core debugging messages"
+	depends on CAN
+	---help---
+	  Say Y here if you want the CAN core to produce a bunch of debug
+	  messages to the system log.  Select this if you are having a
+	  problem with CAN support and want to see more of what is going on.
Index: net-2.6.24/net/can/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/net/can/Makefile	2007-09-25 13:14:46.000000000 +0200
@@ -0,0 +1,6 @@
+#
+#  Makefile for the Linux Controller Area Network core.
+#
+
+obj-$(CONFIG_CAN)	+= can.o
+can-objs		:= af_can.o proc.o
Index: net-2.6.24/net/can/af_can.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/net/can/af_can.c	2007-09-25 13:22:22.000000000 +0200
@@ -0,0 +1,973 @@
+/*
+ * af_can.c - Protocol family CAN core module
+ *            (used by different CAN protocol modules)
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions, the following disclaimer and
+ *    the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/kmod.h>
+#include <linux/slab.h>
+#include <linux/list.h>
+#include <linux/spinlock.h>
+#include <linux/rcupdate.h>
+#include <linux/uaccess.h>
+#include <linux/net.h>
+#include <linux/netdevice.h>
+#include <linux/socket.h>
+#include <linux/if_ether.h>
+#include <linux/if_arp.h>
+#include <linux/skbuff.h>
+#include <linux/can.h>
+#include <linux/can/core.h>
+#include <net/net_namespace.h>
+#include <net/sock.h>
+
+#include "af_can.h"
+
+#define IDENT "core"
+static __initdata const char banner[] = KERN_INFO
+	"can: controller area network core (" CAN_VERSION_STRING ")\n";
+
+MODULE_DESCRIPTION("Controller Area Network PF_CAN core");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>, "
+	      "Oliver Hartkopp <oliver.hartkopp@volkswagen.de>");
+
+MODULE_ALIAS_NETPROTO(PF_CAN);
+
+static int stats_timer __read_mostly = 1;
+module_param(stats_timer, int, S_IRUGO);
+MODULE_PARM_DESC(stats_timer, "enable timer for statistics (default:on)");
+
+#ifdef CONFIG_CAN_DEBUG_CORE
+static int debug __read_mostly;
+module_param(debug, int, S_IRUGO);
+MODULE_PARM_DESC(debug, "debug print mask: 1:debug, 2:frames, 4:skbs");
+#endif
+
+HLIST_HEAD(rx_dev_list);
+static struct dev_rcv_lists rx_alldev_list;
+static DEFINE_SPINLOCK(rcv_lists_lock);
+
+static struct kmem_cache *rcv_cache __read_mostly;
+
+/* table of registered CAN protocols */
+static struct can_proto *proto_tab[CAN_NPROTO] __read_mostly;
+static DEFINE_SPINLOCK(proto_tab_lock);
+
+struct timer_list stattimer; /* timer for statistics update */
+struct s_stats  stats;       /* packet statistics */
+struct s_pstats pstats;      /* receive list statistics */
+
+/*
+ * af_can socket functions
+ */
+
+static int can_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
+{
+	struct sock *sk = sock->sk;
+
+	switch (cmd) {
+
+	case SIOCGSTAMP:
+		return sock_get_timestamp(sk, (struct timeval __user *)arg);
+
+	default:
+		return -ENOIOCTLCMD;
+	}
+}
+
+static void can_sock_destruct(struct sock *sk)
+{
+	DBG("called for sock %p\n", sk);
+
+	skb_queue_purge(&sk->sk_receive_queue);
+	if (sk->sk_protinfo)
+		kfree(sk->sk_protinfo);
+}
+
+static int can_create(struct net *net, struct socket *sock, int protocol)
+{
+	struct sock *sk;
+	struct can_proto *cp;
+	char module_name[sizeof("can-proto-000")];
+	int ret = 0;
+
+	DBG("socket %p, type %d, proto %d\n", sock, sock->type, protocol);
+
+	sock->state = SS_UNCONNECTED;
+
+	if (protocol < 0 || protocol >= CAN_NPROTO)
+		return -EINVAL;
+
+	if (net != &init_net)
+		return -EAFNOSUPPORT;
+
+	DBG("looking up proto %d in proto_tab[]\n", protocol);
+
+	/* try to load protocol module, when CONFIG_KMOD is defined */
+	if (!proto_tab[protocol]) {
+		sprintf(module_name, "can-proto-%d", protocol);
+		ret = request_module(module_name);
+
+		/*
+		 * In case of error we only print a message but don't
+		 * return the error code immediately.  Below we will
+		 * return -EPROTONOSUPPORT
+		 */
+		if (ret == -ENOSYS) {
+			if (printk_ratelimit())
+				printk(KERN_INFO "can: request_module(%s)"
+				        " not implemented.\n", module_name);
+		} else if (ret) {
+			if (printk_ratelimit())
+				printk(KERN_ERR "can: request_module(%s)"
+				       " failed.\n", module_name);
+		}
+	}
+
+	spin_lock(&proto_tab_lock);
+	cp = proto_tab[protocol];
+	if (cp && !try_module_get(cp->prot->owner))
+		cp = NULL;
+	spin_unlock(&proto_tab_lock);
+
+	/* check for success and correct type */
+	if (!cp || cp->type != sock->type) {
+		ret = -EPROTONOSUPPORT;
+		goto errout;
+	}
+
+	if (cp->capability >= 0 && !capable(cp->capability)) {
+		ret = -EPERM;
+		goto errout;
+	}
+
+	sock->ops = cp->ops;
+
+	sk = sk_alloc(net, PF_CAN, GFP_KERNEL, cp->prot, 1);
+	if (!sk) {
+		ret = -ENOMEM;
+		goto errout;
+	}
+
+	sock_init_data(sock, sk);
+	sk->sk_destruct = can_sock_destruct;
+
+	DBG("created sock: %p\n", sk);
+
+	if (sk->sk_prot->init)
+		ret = sk->sk_prot->init(sk);
+
+	if (ret) {
+		/* release sk on errors */
+		sock_orphan(sk);
+		sock_put(sk);
+	}
+
+ errout:
+	module_put(cp->prot->owner);
+	return ret;
+}
+
+/*
+ * af_can tx path
+ */
+
+/**
+ * can_send - transmit a CAN frame (optional with local loopback)
+ * @skb: pointer to socket buffer with CAN frame in data section
+ * @loop: loopback for listeners on local CAN sockets (recommended default!)
+ *
+ * Return:
+ *  0 on success
+ *  -ENETDOWN when the selected interface is down
+ *  -ENOBUFS on full driver queue (see net_xmit_errno())
+ *  -ENOMEM when local loopback failed at calling skb_clone()
+ *  -EPERM when trying to send on a non-CAN interface
+ */
+int can_send(struct sk_buff *skb, int loop)
+{
+	int err;
+
+	if (skb->dev->type != ARPHRD_CAN) {
+		kfree_skb(skb);
+		return -EPERM;
+	}
+
+	if (!(skb->dev->flags & IFF_UP)) {
+		kfree_skb(skb);
+		return -ENETDOWN;
+	}
+
+	skb->protocol = htons(ETH_P_CAN);
+
+	if (loop) {
+		/* local loopback of sent CAN frames */
+
+		/* indication for the CAN driver: do loopback */
+		skb->pkt_type = PACKET_LOOPBACK;
+
+		/*
+		 * The reference to the originating sock may be required
+		 * by the receiving socket to check whether the frame is
+		 * its own. Example: can_raw sockopt CAN_RAW_RECV_OWN_MSGS
+		 * Therefore we have to ensure that skb->sk remains the
+		 * reference to the originating sock by restoring skb->sk
+		 * after each skb_clone() or skb_orphan() usage.
+		 */
+
+		if (!(skb->dev->flags & IFF_LOOPBACK)) {
+			/*
+			 * If the interface is not capable to do loopback
+			 * itself, we do it here.
+			 */
+			struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC);
+
+			if (!newskb) {
+				kfree_skb(skb);
+				return -ENOMEM;
+			}
+
+			newskb->sk = skb->sk;
+			newskb->ip_summed = CHECKSUM_UNNECESSARY;
+			newskb->pkt_type = PACKET_BROADCAST;
+			netif_rx(newskb);
+		}
+	} else {
+		/* indication for the CAN driver: no loopback required */
+		skb->pkt_type = PACKET_HOST;
+	}
+
+	/* send to netdevice */
+	err = dev_queue_xmit(skb);
+	if (err > 0)
+		err = net_xmit_errno(err);
+
+	/* update statistics */
+	stats.tx_frames++;
+	stats.tx_frames_delta++;
+
+	return err;
+}
+EXPORT_SYMBOL(can_send);
+
+/*
+ * af_can rx path
+ */
+
+static struct dev_rcv_lists *find_dev_rcv_lists(struct net_device *dev)
+{
+	struct dev_rcv_lists *d;
+	struct hlist_node *n;
+
+	/*
+	 * find receive list for this device
+	 *
+	 * The hlist_for_each_entry*() macros curse through the list
+	 * using the pointer variable n and set d to the containing
+	 * struct in each list iteration.  Therefore, after list
+	 * iteration, d is unmodified when the list is empty, and it
+	 * points to last list element, when the list is non-empty
+	 * but no match in the loop body is found.  I.e. d is *not*
+	 * NULL when no match is found.  We can, however, use the
+	 * cursor variable n to decide if a match was found.
+	 */
+
+	hlist_for_each_entry_rcu(d, n, &rx_dev_list, list) {
+		if (d->dev == dev)
+			break;
+	}
+
+	return n ? d : NULL;
+}
+
+static struct hlist_head *find_rcv_list(canid_t *can_id, canid_t *mask,
+					struct dev_rcv_lists *d)
+{
+	canid_t inv = *can_id & CAN_INV_FILTER; /* save flag before masking */
+
+	/* filter error frames */
+	if (*mask & CAN_ERR_FLAG) {
+		/* clear CAN_ERR_FLAG in list entry */
+		*mask &= CAN_ERR_MASK;
+		return &d->rx[RX_ERR];
+	}
+
+	/* ensure valid values in can_mask */
+	if (*mask & CAN_EFF_FLAG)
+		*mask &= (CAN_EFF_MASK | CAN_EFF_FLAG | CAN_RTR_FLAG);
+	else
+		*mask &= (CAN_SFF_MASK | CAN_RTR_FLAG);
+
+	/* reduce condition testing at receive time */
+	*can_id &= *mask;
+
+	/* inverse can_id/can_mask filter */
+	if (inv)
+		return &d->rx[RX_INV];
+
+	/* mask == 0 => no condition testing at receive time */
+	if (!(*mask))
+		return &d->rx[RX_ALL];
+
+	/* use extra filterset for the subscription of exactly *ONE* can_id */
+	if (*can_id & CAN_EFF_FLAG) {
+		if (*mask == (CAN_EFF_MASK | CAN_EFF_FLAG)) {
+			/* RFC: a use-case for hash-tables in the future? */
+			return &d->rx[RX_EFF];
+		}
+	} else {
+		if (*mask == CAN_SFF_MASK)
+			return &d->rx_sff[*can_id];
+	}
+
+	/* default: filter via can_id/can_mask */
+	return &d->rx[RX_FIL];
+}
+
+/**
+ * can_rx_register - subscribe CAN frames from a specific interface
+ * @dev: pointer to netdevice (NULL => subcribe from 'all' CAN devices list)
+ * @can_id: CAN identifier (see description)
+ * @mask: CAN mask (see description)
+ * @func: callback function on filter match
+ * @data: returned parameter for callback function
+ * @ident: string for calling module indentification
+ *
+ * Description:
+ *  Invokes the callback function with the received sk_buff and the given
+ *  parameter 'data' on a matching receive filter. A filter matches, when
+ *
+ *          <received_can_id> & mask == can_id & mask
+ *
+ *  The filter can be inverted (CAN_INV_FILTER bit set in can_id) or it can
+ *  filter for error frames (CAN_ERR_FLAG bit set in mask).
+ *
+ * Return:
+ *  0 on success
+ *  -ENOMEM on missing cache mem to create subscription entry
+ *  -ENODEV unknown device
+ */
+int can_rx_register(struct net_device *dev, canid_t can_id, canid_t mask,
+		    void (*func)(struct sk_buff *, void *), void *data,
+		    char *ident)
+{
+	struct receiver *r;
+	struct hlist_head *rl;
+	struct dev_rcv_lists *d;
+	int ret = 0;
+
+	/* insert new receiver  (dev,canid,mask) -> (func,data) */
+
+	DBG("dev %p (%s), id %03X, mask %03X, callback %p, data %p, "
+	    "ident %s\n", dev, DNAME(dev), can_id, mask, func, data, ident);
+
+	r = kmem_cache_alloc(rcv_cache, GFP_KERNEL);
+	if (!r)
+		return -ENOMEM;
+
+	spin_lock(&rcv_lists_lock);
+
+	d = find_dev_rcv_lists(dev);
+	if (d) {
+		rl = find_rcv_list(&can_id, &mask, d);
+
+		r->can_id  = can_id;
+		r->mask    = mask;
+		r->matches = 0;
+		r->func    = func;
+		r->data    = data;
+		r->ident   = ident;
+
+		hlist_add_head_rcu(&r->list, rl);
+		d->entries++;
+
+		pstats.rcv_entries++;
+		if (pstats.rcv_entries_max < pstats.rcv_entries)
+			pstats.rcv_entries_max = pstats.rcv_entries;
+	} else {
+		DBG("receive list not found for dev %s, id %03X, mask %03X\n",
+		    DNAME(dev), can_id, mask);
+		kmem_cache_free(rcv_cache, r);
+		ret = -ENODEV;
+	}
+
+	spin_unlock(&rcv_lists_lock);
+
+	return ret;
+}
+EXPORT_SYMBOL(can_rx_register);
+
+/*
+ * can_rx_delete_device - rcu callback for dev_rcv_lists structure removal
+ */
+static void can_rx_delete_device(struct rcu_head *rp)
+{
+	struct dev_rcv_lists *d = container_of(rp, struct dev_rcv_lists, rcu);
+
+	DBG("removing dev_rcv_list at %p\n", d);
+	kfree(d);
+}
+
+/*
+ * can_rx_delete_receiver - rcu callback for single receiver entry removal
+ */
+static void can_rx_delete_receiver(struct rcu_head *rp)
+{
+	struct receiver *r = container_of(rp, struct receiver, rcu);
+
+	DBG("removing receiver at %p\n", r);
+	kmem_cache_free(rcv_cache, r);
+}
+
+/**
+ * can_rx_unregister - unsubscribe CAN frames from a specific interface
+ * @dev: pointer to netdevice (NULL => unsubcribe from 'all' CAN devices list)
+ * @can_id: CAN identifier
+ * @mask: CAN mask
+ * @func: callback function on filter match
+ * @data: returned parameter for callback function
+ *
+ * Description:
+ *  Removes subscription entry depending on given (subscription) values.
+ */
+void can_rx_unregister(struct net_device *dev, canid_t can_id, canid_t mask,
+		       void (*func)(struct sk_buff *, void *), void *data)
+{
+	struct receiver *r = NULL;
+	struct hlist_head *rl;
+	struct hlist_node *next;
+	struct dev_rcv_lists *d;
+
+	DBG("dev %p (%s), id %03X, mask %03X, callback %p, data %p\n",
+	    dev, DNAME(dev), can_id, mask, func, data);
+
+	spin_lock(&rcv_lists_lock);
+
+	d = find_dev_rcv_lists(dev);
+	if (!d) {
+		printk(KERN_ERR "BUG: receive list not found for "
+		       "dev %s, id %03X, mask %03X\n",
+		       DNAME(dev), can_id, mask);
+		goto out;
+	}
+
+	rl = find_rcv_list(&can_id, &mask, d);
+
+	/*
+	 * Search the receiver list for the item to delete.  This should
+	 * exist, since no receiver may be unregistered that hasn't
+	 * been registered before.
+	 */
+
+	hlist_for_each_entry_rcu(r, next, rl, list) {
+		if (r->can_id == can_id && r->mask == mask
+		    && r->func == func && r->data == data)
+			break;
+	}
+
+	/*
+	 * Check for bug in CAN protocol implementations:
+	 * If no matching list item was found, the list cursor variable next
+	 * will be NULL, while r will point to the last item of the list.
+	 */
+
+	if (!next) {
+		printk(KERN_ERR "BUG: receive list entry not found for "
+		       "dev %s, id %03X, mask %03X\n",
+		       DNAME(dev), can_id, mask);
+		r = NULL;
+		d = NULL;
+		goto out;
+	}
+
+	hlist_del_rcu(&r->list);
+	d->entries--;
+
+	if (pstats.rcv_entries > 0)
+		pstats.rcv_entries--;
+
+	/* remove device structure requested by NETDEV_UNREGISTER */
+	if (d->remove_on_zero_entries && !d->entries) {
+		DBG("removing dev_rcv_list for %s on zero entries\n",
+		    dev->name);
+		hlist_del_rcu(&d->list);
+	} else
+		d = NULL;
+
+ out:
+	spin_unlock(&rcv_lists_lock);
+
+	/* schedule the receiver item for deletion */
+	if (r)
+		call_rcu(&r->rcu, can_rx_delete_receiver);
+
+	/* schedule the device structure for deletion */
+	if (d)
+		call_rcu(&d->rcu, can_rx_delete_device);
+}
+EXPORT_SYMBOL(can_rx_unregister);
+
+static inline void deliver(struct sk_buff *skb, struct receiver *r)
+{
+	struct sk_buff *clone = skb_clone(skb, GFP_ATOMIC);
+
+	DBG("skbuff %p cloned to %p\n", skb, clone);
+	if (clone) {
+		clone->sk = skb->sk;
+		r->func(clone, r->data);
+		r->matches++;
+	}
+}
+
+static int can_rcv_filter(struct dev_rcv_lists *d, struct sk_buff *skb)
+{
+	struct receiver *r;
+	struct hlist_node *n;
+	int matches = 0;
+	struct can_frame *cf = (struct can_frame *)skb->data;
+	canid_t can_id = cf->can_id;
+
+	if (d->entries == 0)
+		return 0;
+
+	if (can_id & CAN_ERR_FLAG) {
+		/* check for error frame entries only */
+		hlist_for_each_entry_rcu(r, n, &d->rx[RX_ERR], list) {
+			if (can_id & r->mask) {
+				DBG("match on rx_err skbuff %p\n", skb);
+				deliver(skb, r);
+				matches++;
+			}
+		}
+		return matches;
+	}
+
+	/* check for unfiltered entries */
+	hlist_for_each_entry_rcu(r, n, &d->rx[RX_ALL], list) {
+		DBG("match on rx_all skbuff %p\n", skb);
+		deliver(skb, r);
+		matches++;
+	}
+
+	/* check for can_id/mask entries */
+	hlist_for_each_entry_rcu(r, n, &d->rx[RX_FIL], list) {
+		if ((can_id & r->mask) == r->can_id) {
+			DBG("match on rx_fil skbuff %p\n", skb);
+			deliver(skb, r);
+			matches++;
+		}
+	}
+
+	/* check for inverted can_id/mask entries */
+	hlist_for_each_entry_rcu(r, n, &d->rx[RX_INV], list) {
+		if ((can_id & r->mask) != r->can_id) {
+			DBG("match on rx_inv skbuff %p\n", skb);
+			deliver(skb, r);
+			matches++;
+		}
+	}
+
+	/* check CAN_ID specific entries */
+	if (can_id & CAN_EFF_FLAG) {
+		hlist_for_each_entry_rcu(r, n, &d->rx[RX_EFF], list) {
+			if (r->can_id == can_id) {
+				DBG("match on rx_eff skbuff %p\n", skb);
+				deliver(skb, r);
+				matches++;
+			}
+		}
+	} else {
+		can_id &= CAN_SFF_MASK;
+		hlist_for_each_entry_rcu(r, n, &d->rx_sff[can_id], list) {
+			DBG("match on rx_sff skbuff %p\n", skb);
+			deliver(skb, r);
+			matches++;
+		}
+	}
+
+	return matches;
+}
+
+static int can_rcv(struct sk_buff *skb, struct net_device *dev,
+		   struct packet_type *pt, struct net_device *orig_dev)
+{
+	struct dev_rcv_lists *d;
+	int matches;
+
+	DBG("received skbuff on device %s, ptype %04x\n",
+	    dev->name, ntohs(pt->type));
+	DBG_SKB(skb);
+	DBG_FRAME("af_can: can_rcv: received CAN frame",
+		  (struct can_frame *)skb->data);
+
+	if (dev->type != ARPHRD_CAN || dev->nd_net != &init_net) {
+		kfree_skb(skb);
+		return 0;
+	}
+
+	/* update statistics */
+	stats.rx_frames++;
+	stats.rx_frames_delta++;
+
+	rcu_read_lock();
+
+	/* deliver the packet to sockets listening on all devices */
+	matches = can_rcv_filter(&rx_alldev_list, skb);
+
+	/* find receive list for this device */
+	d = find_dev_rcv_lists(dev);
+	if (d)
+		matches += can_rcv_filter(d, skb);
+
+	rcu_read_unlock();
+
+	/* free the skbuff allocated by the netdevice driver */
+	DBG("freeing skbuff %p\n", skb);
+	kfree_skb(skb);
+
+	if (matches > 0) {
+		stats.matches++;
+		stats.matches_delta++;
+	}
+
+	return 0;
+}
+
+/*
+ * af_can protocol functions
+ */
+
+/**
+ * can_proto_register - register CAN transport protocol
+ * @cp: pointer to CAN protocol structure
+ *
+ * Return:
+ *  0 on success
+ *  -EINVAL invalid (out of range) protocol number
+ *  -EBUSY  protocol already in use
+ *  -ENOBUF if proto_register() fails
+ */
+int can_proto_register(struct can_proto *cp)
+{
+	int proto = cp->protocol;
+	int err = 0;
+
+	if (proto < 0 || proto >= CAN_NPROTO) {
+		printk(KERN_ERR "can: protocol number %d out of range\n",
+		       proto);
+		return -EINVAL;
+	}
+
+	spin_lock(&proto_tab_lock);
+	if (proto_tab[proto]) {
+		printk(KERN_ERR "can: protocol %d already registered\n",
+		       proto);
+		err = -EBUSY;
+		goto errout;
+	}
+
+	err = proto_register(cp->prot, 0);
+	if (err < 0)
+		goto errout;
+
+	proto_tab[proto] = cp;
+
+	/* use generic ioctl function if the module doesn't bring its own */
+	if (!cp->ops->ioctl)
+		cp->ops->ioctl = can_ioctl;
+
+ errout:
+	spin_unlock(&proto_tab_lock);
+
+	return err;
+}
+EXPORT_SYMBOL(can_proto_register);
+
+/**
+ * can_proto_unregister - unregister CAN transport protocol
+ * @cp: pointer to CAN protocol structure
+ */
+void can_proto_unregister(struct can_proto *cp)
+{
+	int proto = cp->protocol;
+
+	spin_lock(&proto_tab_lock);
+	if (!proto_tab[proto]) {
+		printk(KERN_ERR "BUG: can: protocol %d is not registered\n",
+		       proto);
+	}
+	proto_unregister(cp->prot);
+	proto_tab[proto] = NULL;
+	spin_unlock(&proto_tab_lock);
+}
+EXPORT_SYMBOL(can_proto_unregister);
+
+/*
+ * af_can notifier to create/remove CAN netdevice specific structs
+ */
+static int can_notifier(struct notifier_block *nb, unsigned long msg,
+			void *data)
+{
+	struct net_device *dev = (struct net_device *)data;
+	struct dev_rcv_lists *d;
+
+	DBG("msg %ld for dev %p (%s idx %d)\n",
+	    msg, dev, dev->name, dev->ifindex);
+
+	if (dev->nd_net != &init_net)
+		return NOTIFY_DONE;
+
+	if (dev->type != ARPHRD_CAN)
+		return NOTIFY_DONE;
+
+	switch (msg) {
+
+	case NETDEV_REGISTER:
+
+		/*
+		 * create new dev_rcv_lists for this device
+		 *
+		 * N.B. zeroing the struct is the correct initialization
+		 * for the embedded hlist_head structs.
+		 * Another list type, e.g. list_head, would require
+		 * explicit initialization.
+		 */
+
+		DBG("creating new dev_rcv_lists for %s\n", dev->name);
+
+		d = kzalloc(sizeof(*d), GFP_KERNEL);
+		if (!d) {
+			printk(KERN_ERR
+			       "can: allocation of receive list failed\n");
+			return NOTIFY_DONE;
+		}
+		d->dev = dev;
+
+		spin_lock(&rcv_lists_lock);
+		hlist_add_head_rcu(&d->list, &rx_dev_list);
+		spin_unlock(&rcv_lists_lock);
+
+		break;
+
+	case NETDEV_UNREGISTER:
+		spin_lock(&rcv_lists_lock);
+
+		d = find_dev_rcv_lists(dev);
+		if (d) {
+			DBG("remove dev_rcv_list for %s (%d entries)\n",
+			    dev->name, d->entries);
+
+			if (d->entries) {
+				d->remove_on_zero_entries = 1;
+				d = NULL;
+			} else
+				hlist_del_rcu(&d->list);
+		} else
+			printk(KERN_ERR "can: notifier: receive list not "
+			       "found for dev %s\n", dev->name);
+
+		spin_unlock(&rcv_lists_lock);
+
+		if (d)
+			call_rcu(&d->rcu, can_rx_delete_device);
+
+		break;
+	}
+
+	return NOTIFY_DONE;
+}
+
+/*
+ * af_can debugging stuff
+ */
+
+#ifdef CONFIG_CAN_DEBUG_CORE
+
+/**
+ * can_debug_cframe - print CAN frame
+ * @msg: pointer to message printed before the given CAN frame
+ * @cf: pointer to CAN frame
+ */
+void can_debug_cframe(const char *msg, struct can_frame *cf)
+{
+	char idbuf[12];
+	char hexbuf[28];
+	int dlc;
+
+	dlc = cf->can_dlc;
+	if (dlc > 8)
+		dlc = 8;
+
+	if (cf->can_id & CAN_EFF_FLAG)
+		sprintf(idbuf, "<%08X>", cf->can_id & CAN_EFF_MASK);
+	else
+		sprintf(idbuf, "<%03X>", cf->can_id & CAN_SFF_MASK);
+
+	if (cf->can_id & CAN_RTR_FLAG)
+		sprintf(hexbuf, "(RTR)");
+	else
+		hex_dump_to_buffer(cf->data, dlc, 16, 1, hexbuf, 28, 0);
+
+	printk(KERN_DEBUG "%s: %s [%d] %s\n", msg, idbuf, dlc, hexbuf);
+}
+EXPORT_SYMBOL(can_debug_cframe);
+
+/**
+ * can_debug_skb - print socket buffer content to kernel log
+ * @skb: pointer to socket buffer
+ */
+void can_debug_skb(struct sk_buff *skb)
+{
+	printk(KERN_DEBUG "  skbuff at %p, dev: %d, proto: %04x\n"
+	       KERN_DEBUG "  users: %d, dataref: %d, nr_frags: %d, "
+	       "h,d,t,e,l: %p %+d %+d %+d, %d\n",
+	       skb, skb->dev ? skb->dev->ifindex : -1,
+	       ntohs(skb->protocol),
+	       atomic_read(&skb->users),
+	       atomic_read(&(skb_shinfo(skb)->dataref)),
+	       skb_shinfo(skb)->nr_frags,
+	       skb->head, skb->data - skb->head,
+	       skb->tail - skb->head, skb->end - skb->head, skb->len);
+
+	print_hex_dump(KERN_DEBUG, "skb_head: ", DUMP_PREFIX_NONE,
+		       16, 1, skb->head, skb->end - skb->head, 0);
+}
+EXPORT_SYMBOL(can_debug_skb);
+
+#endif
+
+/*
+ * af_can module init/exit functions
+ */
+
+static struct packet_type can_packet __read_mostly = {
+	.type = __constant_htons(ETH_P_CAN),
+	.dev  = NULL,
+	.func = can_rcv,
+};
+
+static struct net_proto_family can_family_ops __read_mostly = {
+	.family = PF_CAN,
+	.create = can_create,
+	.owner  = THIS_MODULE,
+};
+
+/* notifier block for netdevice event */
+static struct notifier_block can_netdev_notifier __read_mostly = {
+	.notifier_call = can_notifier,
+};
+
+static __init int can_init(void)
+{
+	printk(banner);
+
+	rcv_cache = kmem_cache_create("can_receiver", sizeof(struct receiver),
+				      0, 0, NULL);
+	if (!rcv_cache)
+		return -ENOMEM;
+
+	/*
+	 * Insert rx_alldev_list for reception on all devices.
+	 * This struct is zero initialized which is correct for the
+	 * embedded hlist heads, the dev pointer, and the entries counter.
+	 */
+
+	spin_lock(&rcv_lists_lock);
+	hlist_add_head_rcu(&rx_alldev_list.list, &rx_dev_list);
+	spin_unlock(&rcv_lists_lock);
+
+	if (stats_timer) {
+		/* the statistics are updated every second (timer triggered) */
+		init_timer(&stattimer);
+		stattimer.function = can_stat_update;
+		stattimer.data = 0;
+		/* update every second */
+		stattimer.expires = round_jiffies(jiffies + HZ);
+		/* start statistics timer */
+		add_timer(&stattimer);
+	} else
+		stattimer.function = NULL;
+
+	/* procfs init */
+	can_init_proc();
+
+	/* protocol register */
+	sock_register(&can_family_ops);
+	register_netdevice_notifier(&can_netdev_notifier);
+	dev_add_pack(&can_packet);
+
+	return 0;
+}
+
+static __exit void can_exit(void)
+{
+	struct dev_rcv_lists *d;
+	struct hlist_node *n, *next;
+
+	if (stats_timer)
+		del_timer(&stattimer);
+
+	/* procfs remove */
+	can_remove_proc();
+
+	/* protocol unregister */
+	dev_remove_pack(&can_packet);
+	unregister_netdevice_notifier(&can_netdev_notifier);
+	sock_unregister(PF_CAN);
+
+	/* remove rx_dev_list */
+	spin_lock(&rcv_lists_lock);
+	hlist_del(&rx_alldev_list.list);
+	hlist_for_each_entry_safe(d, n, next, &rx_dev_list, list) {
+		hlist_del(&d->list);
+		kfree(d);
+	}
+	spin_unlock(&rcv_lists_lock);
+
+	kmem_cache_destroy(rcv_cache);
+}
+
+module_init(can_init);
+module_exit(can_exit);
Index: net-2.6.24/net/can/af_can.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/net/can/af_can.h	2007-09-25 13:14:46.000000000 +0200
@@ -0,0 +1,121 @@
+/*
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions, the following disclaimer and
+ *    the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#ifndef AF_CAN_H
+#define AF_CAN_H
+
+#include <linux/skbuff.h>
+#include <linux/netdevice.h>
+#include <linux/list.h>
+#include <linux/rcupdate.h>
+#include <linux/can.h>
+
+/* af_can rx dispatcher structures */
+
+struct receiver {
+	struct hlist_node list;
+	struct rcu_head rcu;
+	canid_t can_id;
+	canid_t mask;
+	unsigned long matches;
+	void (*func)(struct sk_buff *, void *);
+	void *data;
+	char *ident;
+};
+
+enum { RX_ERR, RX_ALL, RX_FIL, RX_INV, RX_EFF, RX_MAX };
+
+struct dev_rcv_lists {
+	struct hlist_node list;
+	struct rcu_head rcu;
+	struct net_device *dev;
+	struct hlist_head rx[RX_MAX];
+	struct hlist_head rx_sff[0x800];
+	int remove_on_zero_entries;
+	int entries;
+};
+
+/* statistic structures */
+
+struct s_stats {
+	unsigned long jiffies_init;
+
+	unsigned long rx_frames;
+	unsigned long tx_frames;
+	unsigned long matches;
+
+	unsigned long total_rx_rate;
+	unsigned long total_tx_rate;
+	unsigned long total_rx_match_ratio;
+
+	unsigned long current_rx_rate;
+	unsigned long current_tx_rate;
+	unsigned long current_rx_match_ratio;
+
+	unsigned long max_rx_rate;
+	unsigned long max_tx_rate;
+	unsigned long max_rx_match_ratio;
+
+	unsigned long rx_frames_delta;
+	unsigned long tx_frames_delta;
+	unsigned long matches_delta;
+}; /* can be reset e.g. by can_init_stats() */
+
+struct s_pstats {
+	unsigned long stats_reset;
+	unsigned long user_reset;
+	unsigned long rcv_entries;
+	unsigned long rcv_entries_max;
+}; /* persistent statistics */
+
+/* function prototypes for the CAN networklayer procfs (proc.c) */
+extern void can_init_proc(void);
+extern void can_remove_proc(void);
+extern void can_stat_update(unsigned long data);
+
+/* structures and variables from af_can.c needed in proc.c for reading */
+extern struct timer_list stattimer;	/* timer for statistics update */
+extern struct s_stats  stats;		/* packet statistics */
+extern struct s_pstats pstats;		/* receive list statistics */
+extern struct hlist_head rx_dev_list;	/* rx dispatcher structures */
+
+#endif /* AF_CAN_H */
Index: net-2.6.24/net/can/proc.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/net/can/proc.c	2007-09-25 13:22:22.000000000 +0200
@@ -0,0 +1,533 @@
+/*
+ * proc.c - procfs support for Protocol family CAN core module
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions, the following disclaimer and
+ *    the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/proc_fs.h>
+#include <linux/list.h>
+#include <linux/rcupdate.h>
+#include <linux/can/core.h>
+
+#include "af_can.h"
+
+/*
+ * proc filenames for the PF_CAN core
+ */
+
+#define CAN_PROC_VERSION     "version"
+#define CAN_PROC_STATS       "stats"
+#define CAN_PROC_RESET_STATS "reset_stats"
+#define CAN_PROC_RCVLIST_ALL "rcvlist_all"
+#define CAN_PROC_RCVLIST_FIL "rcvlist_fil"
+#define CAN_PROC_RCVLIST_INV "rcvlist_inv"
+#define CAN_PROC_RCVLIST_SFF "rcvlist_sff"
+#define CAN_PROC_RCVLIST_EFF "rcvlist_eff"
+#define CAN_PROC_RCVLIST_ERR "rcvlist_err"
+
+static struct proc_dir_entry *can_dir;
+static struct proc_dir_entry *pde_version;
+static struct proc_dir_entry *pde_stats;
+static struct proc_dir_entry *pde_reset_stats;
+static struct proc_dir_entry *pde_rcvlist_all;
+static struct proc_dir_entry *pde_rcvlist_fil;
+static struct proc_dir_entry *pde_rcvlist_inv;
+static struct proc_dir_entry *pde_rcvlist_sff;
+static struct proc_dir_entry *pde_rcvlist_eff;
+static struct proc_dir_entry *pde_rcvlist_err;
+
+static int user_reset;
+
+static const char rx_list_name[][8] = {
+	[RX_ERR] = "rx_err",
+	[RX_ALL] = "rx_all",
+	[RX_FIL] = "rx_fil",
+	[RX_INV] = "rx_inv",
+	[RX_EFF] = "rx_eff",
+};
+
+/*
+ * af_can statistics stuff
+ */
+
+static void can_init_stats(void)
+{
+	/*
+	 * This memset function is called from a timer context (when
+	 * stattimer is active which is the default) OR in a process
+	 * context (reading the proc_fs when stattimer is disabled).
+	 */
+	memset(&stats, 0, sizeof(stats));
+	stats.jiffies_init = jiffies;
+
+	pstats.stats_reset++;
+
+	if (user_reset) {
+		user_reset = 0;
+		pstats.user_reset++;
+	}
+}
+
+static unsigned long calc_rate(unsigned long oldjif, unsigned long newjif,
+			       unsigned long count)
+{
+	unsigned long ret = 0;
+
+	if (oldjif == newjif)
+		return 0;
+
+	/* see can_stat_update() - this should NEVER happen! */
+	if (count > (ULONG_MAX / HZ)) {
+		printk(KERN_ERR "can: calc_rate: count exceeded! %ld\n",
+		       count);
+		return 99999999;
+	}
+
+	ret = (count * HZ) / (newjif - oldjif);
+
+	return ret;
+}
+
+void can_stat_update(unsigned long data)
+{
+	unsigned long j = jiffies; /* snapshot */
+
+	/* restart counting in timer context on user request */
+	if (user_reset)
+		can_init_stats();
+
+	/* restart counting on jiffies overflow */
+	if (j < stats.jiffies_init)
+		can_init_stats();
+
+	/* prevent overflow in calc_rate() */
+	if (stats.rx_frames > (ULONG_MAX / HZ))
+		can_init_stats();
+
+	/* prevent overflow in calc_rate() */
+	if (stats.tx_frames > (ULONG_MAX / HZ))
+		can_init_stats();
+
+	/* matches overflow - very improbable */
+	if (stats.matches > (ULONG_MAX / 100))
+		can_init_stats();
+
+	/* calc total values */
+	if (stats.rx_frames)
+		stats.total_rx_match_ratio = (stats.matches * 100) /
+						stats.rx_frames;
+
+	stats.total_tx_rate = calc_rate(stats.jiffies_init, j,
+					stats.tx_frames);
+	stats.total_rx_rate = calc_rate(stats.jiffies_init, j,
+					stats.rx_frames);
+
+	/* calc current values */
+	if (stats.rx_frames_delta)
+		stats.current_rx_match_ratio =
+			(stats.matches_delta * 100) / stats.rx_frames_delta;
+
+	stats.current_tx_rate = calc_rate(0, HZ, stats.tx_frames_delta);
+	stats.current_rx_rate = calc_rate(0, HZ, stats.rx_frames_delta);
+
+	/* check / update maximum values */
+	if (stats.max_tx_rate < stats.current_tx_rate)
+		stats.max_tx_rate = stats.current_tx_rate;
+
+	if (stats.max_rx_rate < stats.current_rx_rate)
+		stats.max_rx_rate = stats.current_rx_rate;
+
+	if (stats.max_rx_match_ratio < stats.current_rx_match_ratio)
+		stats.max_rx_match_ratio = stats.current_rx_match_ratio;
+
+	/* clear values for 'current rate' calculation */
+	stats.tx_frames_delta = 0;
+	stats.rx_frames_delta = 0;
+	stats.matches_delta   = 0;
+
+	/* restart timer (one second) */
+	stattimer.expires = round_jiffies(jiffies + HZ);
+	add_timer(&stattimer);
+}
+
+/*
+ * proc read functions
+ *
+ * From known use-cases we expect about 10 entries in a receive list to be
+ * printed in the proc_fs. So PAGE_SIZE is definitely enough space here.
+ *
+ */
+
+static int can_print_rcvlist(char *page, int len, struct hlist_head *rx_list,
+			     struct net_device *dev)
+{
+	struct receiver *r;
+	struct hlist_node *n;
+
+	rcu_read_lock();
+	hlist_for_each_entry_rcu(r, n, rx_list, list) {
+		char *fmt = (r->can_id & CAN_EFF_FLAG)?
+			"   %-5s  %08X  %08x  %08x  %08x  %8ld  %s\n" :
+			"   %-5s     %03X    %08x  %08lx  %08lx  %8ld  %s\n";
+
+		len += snprintf(page + len, PAGE_SIZE - len, fmt,
+				DNAME(dev), r->can_id, r->mask,
+				(unsigned long)r->func, (unsigned long)r->data,
+				r->matches, r->ident);
+
+		/* does a typical line fit into the current buffer? */
+
+		/* 100 Bytes before end of buffer */
+		if (len > PAGE_SIZE - 100) {
+			/* mark output cut off */
+			len += snprintf(page + len, PAGE_SIZE - len,
+					"   (..)\n");
+			break;
+		}
+	}
+	rcu_read_unlock();
+
+	return len;
+}
+
+static int can_print_recv_banner(char *page, int len)
+{
+	/*
+	 *                  can1.  00000000  00000000  00000000
+	 *                 .......          0  tp20
+	 */
+	len += snprintf(page + len, PAGE_SIZE - len,
+			"  device   can_id   can_mask  function"
+			"  userdata   matches  ident\n");
+
+	return len;
+}
+
+static int can_proc_read_stats(char *page, char **start, off_t off,
+			       int count, int *eof, void *data)
+{
+	int len = 0;
+
+	len += snprintf(page + len, PAGE_SIZE - len, "\n");
+	len += snprintf(page + len, PAGE_SIZE - len,
+			" %8ld transmitted frames (TXF)\n", stats.tx_frames);
+	len += snprintf(page + len, PAGE_SIZE - len,
+			" %8ld received frames (RXF)\n", stats.rx_frames);
+	len += snprintf(page + len, PAGE_SIZE - len,
+			" %8ld matched frames (RXMF)\n", stats.matches);
+
+	len += snprintf(page + len, PAGE_SIZE - len, "\n");
+
+	if (stattimer.function == can_stat_update) {
+		len += snprintf(page + len, PAGE_SIZE - len,
+				" %8ld %% total match ratio (RXMR)\n",
+				stats.total_rx_match_ratio);
+
+		len += snprintf(page + len, PAGE_SIZE - len,
+				" %8ld frames/s total tx rate (TXR)\n",
+				stats.total_tx_rate);
+		len += snprintf(page + len, PAGE_SIZE - len,
+				" %8ld frames/s total rx rate (RXR)\n",
+				stats.total_rx_rate);
+
+		len += snprintf(page + len, PAGE_SIZE - len, "\n");
+
+		len += snprintf(page + len, PAGE_SIZE - len,
+				" %8ld %% current match ratio (CRXMR)\n",
+				stats.current_rx_match_ratio);
+
+		len += snprintf(page + len, PAGE_SIZE - len,
+				" %8ld frames/s current tx rate (CTXR)\n",
+				stats.current_tx_rate);
+		len += snprintf(page + len, PAGE_SIZE - len,
+				" %8ld frames/s current rx rate (CRXR)\n",
+				stats.current_rx_rate);
+
+		len += snprintf(page + len, PAGE_SIZE - len, "\n");
+
+		len += snprintf(page + len, PAGE_SIZE - len,
+				" %8ld %% max match ratio (MRXMR)\n",
+				stats.max_rx_match_ratio);
+
+		len += snprintf(page + len, PAGE_SIZE - len,
+				" %8ld frames/s max tx rate (MTXR)\n",
+				stats.max_tx_rate);
+		len += snprintf(page + len, PAGE_SIZE - len,
+				" %8ld frames/s max rx rate (MRXR)\n",
+				stats.max_rx_rate);
+
+		len += snprintf(page + len, PAGE_SIZE - len, "\n");
+	}
+
+	len += snprintf(page + len, PAGE_SIZE - len,
+			" %8ld current receive list entries (CRCV)\n",
+			pstats.rcv_entries);
+	len += snprintf(page + len, PAGE_SIZE - len,
+			" %8ld maximum receive list entries (MRCV)\n",
+			pstats.rcv_entries_max);
+
+	if (pstats.stats_reset)
+		len += snprintf(page + len, PAGE_SIZE - len,
+				"\n %8ld statistic resets (STR)\n",
+				pstats.stats_reset);
+
+	if (pstats.user_reset)
+		len += snprintf(page + len, PAGE_SIZE - len,
+				" %8ld user statistic resets (USTR)\n",
+				pstats.user_reset);
+
+	len += snprintf(page + len, PAGE_SIZE - len, "\n");
+
+	*eof = 1;
+	return len;
+}
+
+static int can_proc_read_reset_stats(char *page, char **start, off_t off,
+				     int count, int *eof, void *data)
+{
+	int len = 0;
+
+	user_reset = 1;
+
+	if (stattimer.function == can_stat_update) {
+		len += snprintf(page + len, PAGE_SIZE - len,
+				"Scheduled statistic reset #%ld.\n",
+				pstats.stats_reset + 1);
+
+	} else {
+		if (stats.jiffies_init != jiffies)
+			can_init_stats();
+
+		len += snprintf(page + len, PAGE_SIZE - len,
+				"Performed statistic reset #%ld.\n",
+				pstats.stats_reset);
+	}
+
+	*eof = 1;
+	return len;
+}
+
+static int can_proc_read_version(char *page, char **start, off_t off,
+				 int count, int *eof, void *data)
+{
+	int len = 0;
+
+	len += snprintf(page + len, PAGE_SIZE - len, "%s\n",
+			CAN_VERSION_STRING);
+	*eof = 1;
+	return len;
+}
+
+static int can_proc_read_rcvlist(char *page, char **start, off_t off,
+				 int count, int *eof, void *data)
+{
+	/* double cast to prevent GCC warning */
+	int idx = (int)(long)data;
+	int len = 0;
+	struct dev_rcv_lists *d;
+	struct hlist_node *n;
+
+	len += snprintf(page + len, PAGE_SIZE - len,
+			"\nreceive list '%s':\n", rx_list_name[idx]);
+
+	rcu_read_lock();
+	hlist_for_each_entry_rcu(d, n, &rx_dev_list, list) {
+
+		if (!hlist_empty(&d->rx[idx])) {
+			len = can_print_recv_banner(page, len);
+			len = can_print_rcvlist(page, len, &d->rx[idx], d->dev);
+		} else
+			len += snprintf(page + len, PAGE_SIZE - len,
+					"  (%s: no entry)\n", DNAME(d->dev));
+
+		/* exit on end of buffer? */
+		if (len > PAGE_SIZE - 100)
+			break;
+	}
+	rcu_read_unlock();
+
+	len += snprintf(page + len, PAGE_SIZE - len, "\n");
+
+	*eof = 1;
+	return len;
+}
+
+static int can_proc_read_rcvlist_sff(char *page, char **start, off_t off,
+				     int count, int *eof, void *data)
+{
+	int len = 0;
+	struct dev_rcv_lists *d;
+	struct hlist_node *n;
+
+	/* RX_SFF */
+	len += snprintf(page + len, PAGE_SIZE - len,
+			"\nreceive list 'rx_sff':\n");
+
+	rcu_read_lock();
+	hlist_for_each_entry_rcu(d, n, &rx_dev_list, list) {
+		int i, all_empty = 1;
+		/* check wether at least one list is non-empty */
+		for (i = 0; i < 0x800; i++)
+			if (!hlist_empty(&d->rx_sff[i])) {
+				all_empty = 0;
+				break;
+			}
+
+		if (!all_empty) {
+			len = can_print_recv_banner(page, len);
+			for (i = 0; i < 0x800; i++) {
+				if (!hlist_empty(&d->rx_sff[i]) &&
+				    len < PAGE_SIZE - 100)
+					len = can_print_rcvlist(page, len,
+								&d->rx_sff[i],
+								d->dev);
+			}
+		} else
+			len += snprintf(page + len, PAGE_SIZE - len,
+					"  (%s: no entry)\n", DNAME(d->dev));
+
+		/* exit on end of buffer? */
+		if (len > PAGE_SIZE - 100)
+			break;
+	}
+	rcu_read_unlock();
+
+	len += snprintf(page + len, PAGE_SIZE - len, "\n");
+
+	*eof = 1;
+	return len;
+}
+
+/*
+ * proc utility functions
+ */
+
+static struct proc_dir_entry *can_create_proc_readentry(const char *name,
+							mode_t mode,
+							read_proc_t *read_proc,
+							void *data)
+{
+	if (can_dir)
+		return create_proc_read_entry(name, mode, can_dir, read_proc,
+					      data);
+	else
+		return NULL;
+}
+
+static void can_remove_proc_readentry(const char *name)
+{
+	if (can_dir)
+		remove_proc_entry(name, can_dir);
+}
+
+/*
+ * can_init_proc - create main CAN proc directory and procfs entries
+ */
+void can_init_proc(void)
+{
+	/* create /proc/net/can directory */
+	can_dir = proc_mkdir("can", init_net.proc_net);
+
+	if (!can_dir) {
+		printk(KERN_INFO "can: failed to create /proc/net/can . "
+		       "CONFIG_PROC_FS missing?\n");
+		return;
+	}
+
+	can_dir->owner = THIS_MODULE;
+
+	/* own procfs entries from the AF_CAN core */
+	pde_version     = can_create_proc_readentry(CAN_PROC_VERSION, 0644,
+					can_proc_read_version, NULL);
+	pde_stats       = can_create_proc_readentry(CAN_PROC_STATS, 0644,
+					can_proc_read_stats, NULL);
+	pde_reset_stats = can_create_proc_readentry(CAN_PROC_RESET_STATS, 0644,
+					can_proc_read_reset_stats, NULL);
+	pde_rcvlist_err = can_create_proc_readentry(CAN_PROC_RCVLIST_ERR, 0644,
+					can_proc_read_rcvlist, (void *)RX_ERR);
+	pde_rcvlist_all = can_create_proc_readentry(CAN_PROC_RCVLIST_ALL, 0644,
+					can_proc_read_rcvlist, (void *)RX_ALL);
+	pde_rcvlist_fil = can_create_proc_readentry(CAN_PROC_RCVLIST_FIL, 0644,
+					can_proc_read_rcvlist, (void *)RX_FIL);
+	pde_rcvlist_inv = can_create_proc_readentry(CAN_PROC_RCVLIST_INV, 0644,
+					can_proc_read_rcvlist, (void *)RX_INV);
+	pde_rcvlist_eff = can_create_proc_readentry(CAN_PROC_RCVLIST_EFF, 0644,
+					can_proc_read_rcvlist, (void *)RX_EFF);
+	pde_rcvlist_sff = can_create_proc_readentry(CAN_PROC_RCVLIST_SFF, 0644,
+					can_proc_read_rcvlist_sff, NULL);
+}
+
+/*
+ * can_remove_proc - remove procfs entries and main CAN proc directory
+ */
+void can_remove_proc(void)
+{
+	if (pde_version)
+		can_remove_proc_readentry(CAN_PROC_VERSION);
+
+	if (pde_stats)
+		can_remove_proc_readentry(CAN_PROC_STATS);
+
+	if (pde_reset_stats)
+		can_remove_proc_readentry(CAN_PROC_RESET_STATS);
+
+	if (pde_rcvlist_err)
+		can_remove_proc_readentry(CAN_PROC_RCVLIST_ERR);
+
+	if (pde_rcvlist_all)
+		can_remove_proc_readentry(CAN_PROC_RCVLIST_ALL);
+
+	if (pde_rcvlist_fil)
+		can_remove_proc_readentry(CAN_PROC_RCVLIST_FIL);
+
+	if (pde_rcvlist_inv)
+		can_remove_proc_readentry(CAN_PROC_RCVLIST_INV);
+
+	if (pde_rcvlist_eff)
+		can_remove_proc_readentry(CAN_PROC_RCVLIST_EFF);
+
+	if (pde_rcvlist_sff)
+		can_remove_proc_readentry(CAN_PROC_RCVLIST_SFF);
+
+	if (can_dir)
+		proc_net_remove(&init_net, "can");
+}
Index: net-2.6.24/include/linux/can/error.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/include/linux/can/error.h	2007-09-25 13:14:46.000000000 +0200
@@ -0,0 +1,93 @@
+/*
+ * linux/can/error.h
+ *
+ * Definitions of the CAN error frame to be filtered and passed to the user.
+ *
+ * Author: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#ifndef CAN_ERROR_H
+#define CAN_ERROR_H
+
+#define CAN_ERR_DLC 8 /* dlc for error frames */
+
+/* error class (mask) in can_id */
+#define CAN_ERR_TX_TIMEOUT   0x00000001U /* TX timeout (by netdevice driver) */
+#define CAN_ERR_LOSTARB      0x00000002U /* lost arbitration    / data[0]    */
+#define CAN_ERR_CRTL         0x00000004U /* controller problems / data[1]    */
+#define CAN_ERR_PROT         0x00000008U /* protocol violations / data[2..3] */
+#define CAN_ERR_TRX          0x00000010U /* transceiver status  / data[4]    */
+#define CAN_ERR_ACK          0x00000020U /* received no ACK on transmission */
+#define CAN_ERR_BUSOFF       0x00000040U /* bus off */
+#define CAN_ERR_BUSERROR     0x00000080U /* bus error (may flood!) */
+#define CAN_ERR_RESTARTED    0x00000100U /* controller restarted */
+
+/* arbitration lost in bit ... / data[0] */
+#define CAN_ERR_LOSTARB_UNSPEC   0x00 /* unspecified */
+				      /* else bit number in bitstream */
+
+/* error status of CAN-controller / data[1] */
+#define CAN_ERR_CRTL_UNSPEC      0x00 /* unspecified */
+#define CAN_ERR_CRTL_RX_OVERFLOW 0x01 /* RX buffer overflow */
+#define CAN_ERR_CRTL_TX_OVERFLOW 0x02 /* TX buffer overflow */
+#define CAN_ERR_CRTL_RX_WARNING  0x04 /* reached warning level for RX errors */
+#define CAN_ERR_CRTL_TX_WARNING  0x08 /* reached warning level for TX errors */
+#define CAN_ERR_CRTL_RX_PASSIVE  0x10 /* reached error passive status RX */
+#define CAN_ERR_CRTL_TX_PASSIVE  0x20 /* reached error passive status TX */
+				      /* (at least one error counter exceeds */
+				      /* the protocol-defined level of 127)  */
+
+/* error in CAN protocol (type) / data[2] */
+#define CAN_ERR_PROT_UNSPEC      0x00 /* unspecified */
+#define CAN_ERR_PROT_BIT         0x01 /* single bit error */
+#define CAN_ERR_PROT_FORM        0x02 /* frame format error */
+#define CAN_ERR_PROT_STUFF       0x04 /* bit stuffing error */
+#define CAN_ERR_PROT_BIT0        0x08 /* unable to send dominant bit */
+#define CAN_ERR_PROT_BIT1        0x10 /* unable to send recessive bit */
+#define CAN_ERR_PROT_OVERLOAD    0x20 /* bus overload */
+#define CAN_ERR_PROT_ACTIVE      0x40 /* active error announcement */
+#define CAN_ERR_PROT_TX          0x80 /* error occured on transmission */
+
+/* error in CAN protocol (location) / data[3] */
+#define CAN_ERR_PROT_LOC_UNSPEC  0x00 /* unspecified */
+#define CAN_ERR_PROT_LOC_SOF     0x03 /* start of frame */
+#define CAN_ERR_PROT_LOC_ID28_21 0x02 /* ID bits 28 - 21 (SFF: 10 - 3) */
+#define CAN_ERR_PROT_LOC_ID20_18 0x06 /* ID bits 20 - 18 (SFF: 2 - 0 )*/
+#define CAN_ERR_PROT_LOC_SRTR    0x04 /* substitute RTR (SFF: RTR) */
+#define CAN_ERR_PROT_LOC_IDE     0x05 /* identifier extension */
+#define CAN_ERR_PROT_LOC_ID17_13 0x07 /* ID bits 17-13 */
+#define CAN_ERR_PROT_LOC_ID12_05 0x0F /* ID bits 12-5 */
+#define CAN_ERR_PROT_LOC_ID04_00 0x0E /* ID bits 4-0 */
+#define CAN_ERR_PROT_LOC_RTR     0x0C /* RTR */
+#define CAN_ERR_PROT_LOC_RES1    0x0D /* reserved bit 1 */
+#define CAN_ERR_PROT_LOC_RES0    0x09 /* reserved bit 0 */
+#define CAN_ERR_PROT_LOC_DLC     0x0B /* data length code */
+#define CAN_ERR_PROT_LOC_DATA    0x0A /* data section */
+#define CAN_ERR_PROT_LOC_CRC_SEQ 0x08 /* CRC sequence */
+#define CAN_ERR_PROT_LOC_CRC_DEL 0x18 /* CRC delimiter */
+#define CAN_ERR_PROT_LOC_ACK     0x19 /* ACK slot */
+#define CAN_ERR_PROT_LOC_ACK_DEL 0x1B /* ACK delimiter */
+#define CAN_ERR_PROT_LOC_EOF     0x1A /* end of frame */
+#define CAN_ERR_PROT_LOC_INTERM  0x12 /* intermission */
+
+/* error status of CAN-transceiver / data[4] */
+/*                                             CANH CANL */
+#define CAN_ERR_TRX_UNSPEC             0x00 /* 0000 0000 */
+#define CAN_ERR_TRX_CANH_NO_WIRE       0x04 /* 0000 0100 */
+#define CAN_ERR_TRX_CANH_SHORT_TO_BAT  0x05 /* 0000 0101 */
+#define CAN_ERR_TRX_CANH_SHORT_TO_VCC  0x06 /* 0000 0110 */
+#define CAN_ERR_TRX_CANH_SHORT_TO_GND  0x07 /* 0000 0111 */
+#define CAN_ERR_TRX_CANL_NO_WIRE       0x40 /* 0100 0000 */
+#define CAN_ERR_TRX_CANL_SHORT_TO_BAT  0x50 /* 0101 0000 */
+#define CAN_ERR_TRX_CANL_SHORT_TO_VCC  0x60 /* 0110 0000 */
+#define CAN_ERR_TRX_CANL_SHORT_TO_GND  0x70 /* 0111 0000 */
+#define CAN_ERR_TRX_CANL_SHORT_TO_CANH 0x80 /* 1000 0000 */
+
+/* controller specific additional information / data[5..7] */
+
+#endif /* CAN_ERROR_H */

--

Re: [PATCH 2/7] CAN: Add PF_CAN core module

[Arnaldo Carvalho de Melo]

Em Tue, Sep 25, 2007 at 02:20:31PM +0200, Urs Thuermann escreveu:
> +
> +static void can_sock_destruct(struct sock *sk)
> +{
> +	DBG("called for sock %p\n", sk);
> +
> +	skb_queue_purge(&sk->sk_receive_queue);
> +	if (sk->sk_protinfo)
> +		kfree(sk->sk_protinfo);
> +}

Is it really needed to do this sk_protinfo check? You don't use it and
it is going to be removed (only user is one of the HAM radio protocols),
so it would be better to not add any more references to this struct sock
field.

- Arnaldo

Re: [PATCH 2/7] CAN: Add PF_CAN core module

[Urs Thuermann]

Arnaldo Carvalho de Melo <acme@ghostprotocols.net> writes:

> > +	skb_queue_purge(&sk->sk_receive_queue);
> > +	if (sk->sk_protinfo)
> > +		kfree(sk->sk_protinfo);
> > +}
> 
> Is it really needed to do this sk_protinfo check?

Thanks for finding this.  This is from 2.6.12 times or so.  We have
other CAN protocol (which we are not allowed to put under GPL)
implemenatations which still use the protinfo field.  But we should
change those and I will delete this check.

urs

Re: [PATCH 2/7] CAN: Add PF_CAN core module

[Stephen Hemminger]

On 25 Sep 2007 15:24:33 +0200
Urs Thuermann <urs@isnogud.escape.de> wrote:

> Arnaldo Carvalho de Melo <acme@ghostprotocols.net> writes:
> 
> > > +	skb_queue_purge(&sk->sk_receive_queue);
> > > +	if (sk->sk_protinfo)
> > > +		kfree(sk->sk_protinfo);
> > > +}
> > 
> > Is it really needed to do this sk_protinfo check?
> 
> Thanks for finding this.  This is from 2.6.12 times or so.  We have
> other CAN protocol (which we are not allowed to put under GPL)
> implemenatations which still use the protinfo field.  But we should
> change those and I will delete this check.
> 
> urs

Then please make all exported symbols marked EXPORT_SYMBOL_GPL to make
sure that the other CAN protocol can not reuse your infrastructure.

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: [PATCH 2/7] CAN: Add PF_CAN core module

[Urs Thuermann]

Stephen Hemminger <shemminger@linux-foundation.org> writes:

> Then please make all exported symbols marked EXPORT_SYMBOL_GPL to make
> sure that the other CAN protocol can not reuse your infrastructure.

We don't want to force other CAN protocol implementations to be GPL
also.  AFAIR from discussions on LKML, it was mostly agreed upon that
this decision is up to the authors of code.

urs

Re: [PATCH 2/7] CAN: Add PF_CAN core module

[Stephen Hemminger]

On 25 Sep 2007 23:00:15 +0200
Urs Thuermann <urs@isnogud.escape.de> wrote:

> Stephen Hemminger <shemminger@linux-foundation.org> writes:
> 
> > Then please make all exported symbols marked EXPORT_SYMBOL_GPL to
> > make sure that the other CAN protocol can not reuse your
> > infrastructure.
> 
> We don't want to force other CAN protocol implementations to be GPL
> also.  AFAIR from discussions on LKML, it was mostly agreed upon that
> this decision is up to the authors of code.
> 
> urs

I just don't want proprietary drivers extensions in linux kernel.
EXPORT_SYMBOL has no meaning in other OS environments.

Re: [PATCH 2/7] CAN: Add PF_CAN core module

[David Miller]

From: Urs Thuermann <urs@isnogud.escape.de>
Date: 25 Sep 2007 23:00:15 +0200

> Stephen Hemminger <shemminger@linux-foundation.org> writes:
> 
> > Then please make all exported symbols marked EXPORT_SYMBOL_GPL to make
> > sure that the other CAN protocol can not reuse your infrastructure.
> 
> We don't want to force other CAN protocol implementations to be GPL
> also.  AFAIR from discussions on LKML, it was mostly agreed upon that
> this decision is up to the authors of code.

To a certain extent, yes.

However, the core issue is whether anyone who uses the symbol
is creating a derivative work.  If it is pretty clear that this
is the case, you really should mark the exported symbols GPL.

In my opinion, in this case it is pretty clear that any use of
these new symbols would be a derivative work and therefore they
all should be marked GPL.

Re: [PATCH 2/7] CAN: Add PF_CAN core module

[Thomas Gleixner]

On Tue, 2007-09-25 at 14:09 -0700, David Miller wrote:
> > > Then please make all exported symbols marked EXPORT_SYMBOL_GPL to make
> > > sure that the other CAN protocol can not reuse your infrastructure.
> > 
> > We don't want to force other CAN protocol implementations to be GPL
> > also.  AFAIR from discussions on LKML, it was mostly agreed upon that
> > this decision is up to the authors of code.
> 
> To a certain extent, yes.
> 
> However, the core issue is whether anyone who uses the symbol
> is creating a derivative work.  If it is pretty clear that this
> is the case, you really should mark the exported symbols GPL.
> 
> In my opinion, in this case it is pretty clear that any use of
> these new symbols would be a derivative work and therefore they
> all should be marked GPL.

Hmm, the code in question is dual licensed. So it's not that clear to
me. 

But it's a legal grey area anyway if somebody loads non GPL code into
the kernel, though IANAL and we can spend years on this discussion.

I'm not inclined either way and we really should not make this a
religious question whether that code goes in or not, especially not when
we granted the mac80211 to export everything w/o _GPL suffix not too
long ago.

Thanks,

	tglx

Re: [PATCH 2/7] CAN: Add PF_CAN core module

[David Miller]

From: Thomas Gleixner <tglx@linutronix.de>
Date: Fri, 28 Sep 2007 18:27:19 +0200

> I'm not inclined either way and we really should not make this a
> religious question whether that code goes in or not, especially not when
> we granted the mac80211 to export everything w/o _GPL suffix not too
> long ago.

This is because a wireless driver is a driver.  It can exist outside
of the kernel and it's mac80211 stack just like any other network
device driver.  ANd the interfaces in mac80211 are such that the
driver doesn't explicitly go into the internals of the implementation.

That's not true with CAN.

With this CAN stuff, any driver you write for it is intimately
integrated into the design and architecture of the CAN subsystem.  Any
such driver cannot stand on it's own.  Look at how these drivers can
get into the internals.

If this code goes in without the _GPL() exports, that's fine, but it's
setting incorrect expectations for people who think they can write
binary-only drivers and link to these symbols.

And it will be the CAN folks who are guilty of setting these
false premises.  Especially after I've explicitly warned about
it here.

Re: [PATCH 2/7] CAN: Add PF_CAN core module

[Thomas Gleixner]

On Fri, 2007-09-28 at 13:20 -0700, David Miller wrote:
> That's not true with CAN.
> 
> With this CAN stuff, any driver you write for it is intimately
> integrated into the design and architecture of the CAN subsystem.  Any
> such driver cannot stand on it's own.  Look at how these drivers can
> get into the internals.

I'm just concerned about protocols, which have been designed and
implemented long ago outside of the kernel and are going to be wrapped
with glue code to fit into the socket can implementation. That's hard to
judge.

> If this code goes in without the _GPL() exports, that's fine, but it's
> setting incorrect expectations for people who think they can write
> binary-only drivers and link to these symbols.
> 
> And it will be the CAN folks who are guilty of setting these
> false premises.  Especially after I've explicitly warned about
> it here.

Fair enough.

	tglx

[PATCH 3/7] CAN: Add raw protocol

[Urs Thuermann]

[-- Attachment #1: 03-can-raw-proto.diff --]
[-- Type: text/plain, Size: 22583 bytes --]

This patch adds the CAN raw protocol.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 include/linux/can/raw.h |   31 +
 net/can/Kconfig         |   11 
 net/can/Makefile        |    3 
 net/can/raw.c           |  822 ++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 867 insertions(+)

Index: net-2.6.24/include/linux/can/raw.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/include/linux/can/raw.h	2007-09-25 13:23:05.000000000 +0200
@@ -0,0 +1,31 @@
+/*
+ * linux/can/raw.h
+ *
+ * Definitions for raw CAN sockets
+ *
+ * Authors: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
+ *          Urs Thuermann   <urs.thuermann@volkswagen.de>
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#ifndef CAN_RAW_H
+#define CAN_RAW_H
+
+#include <linux/can.h>
+
+#define SOL_CAN_RAW (SOL_CAN_BASE + CAN_RAW)
+
+/* for socket options affecting the socket (not the global system) */
+
+enum {
+	CAN_RAW_FILTER = 1,	/* set 0 .. n can_filter(s)          */
+	CAN_RAW_ERR_FILTER,	/* set filter for error frames       */
+	CAN_RAW_LOOPBACK,	/* local loopback (default:on)       */
+	CAN_RAW_RECV_OWN_MSGS	/* receive my own msgs (default:off) */
+};
+
+#endif
Index: net-2.6.24/net/can/Kconfig
===================================================================
--- net-2.6.24.orig/net/can/Kconfig	2007-09-25 13:14:46.000000000 +0200
+++ net-2.6.24/net/can/Kconfig	2007-09-25 13:31:06.000000000 +0200
@@ -16,6 +16,17 @@
 	  If you want CAN support, you should say Y here and also to the
 	  specific driver for your controller(s) below.
 
+config CAN_RAW
+	tristate "Raw CAN Protocol (raw access with CAN-ID filtering)"
+	depends on CAN
+	default N
+	---help---
+	  The Raw CAN protocol option offers access to the CAN bus via
+	  the BSD socket API. You probably want to use the raw socket in
+	  most cases where no higher level protocol is being used. The raw
+	  socket has several filter options e.g. ID-Masking / Errorframes.
+	  To receive/send raw CAN messages, use AF_CAN with protocol CAN_RAW.
+
 config CAN_DEBUG_CORE
 	bool "CAN Core debugging messages"
 	depends on CAN
Index: net-2.6.24/net/can/Makefile
===================================================================
--- net-2.6.24.orig/net/can/Makefile	2007-09-25 13:14:46.000000000 +0200
+++ net-2.6.24/net/can/Makefile	2007-09-25 13:29:23.000000000 +0200
@@ -4,3 +4,6 @@
 
 obj-$(CONFIG_CAN)	+= can.o
 can-objs		:= af_can.o proc.o
+
+obj-$(CONFIG_CAN_RAW)	+= can-raw.o
+can-raw-objs		:= raw.o
Index: net-2.6.24/net/can/raw.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/net/can/raw.c	2007-09-25 13:25:24.000000000 +0200
@@ -0,0 +1,822 @@
+/*
+ * raw.c - Raw sockets for protocol family CAN
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions, the following disclaimer and
+ *    the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/uio.h>
+#include <linux/poll.h>
+#include <linux/net.h>
+#include <linux/netdevice.h>
+#include <linux/socket.h>
+#include <linux/if_arp.h>
+#include <linux/skbuff.h>
+#include <linux/can.h>
+#include <linux/can/core.h>
+#include <linux/can/raw.h>
+#include <net/sock.h>
+#include <net/net_namespace.h>
+
+#define IDENT "raw"
+#define CAN_RAW_VERSION CAN_VERSION
+static __initdata const char banner[] =
+	KERN_INFO "can: raw protocol (rev " CAN_RAW_VERSION ")\n";
+
+MODULE_DESCRIPTION("PF_CAN raw protocol");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
+
+#ifdef CONFIG_CAN_DEBUG_CORE
+static int debug;
+module_param(debug, int, S_IRUGO);
+MODULE_PARM_DESC(debug, "debug print mask: 1:debug, 2:frames, 4:skbs");
+#endif
+
+#define MASK_ALL 0
+
+/*
+ * A raw socket has a list of can_filters attached to it, each receiving
+ * the CAN frames matching that filter.  If the filter list is empty,
+ * no CAN frames will be received by the socket.  The default after
+ * opening the socket, is to have one filter which receives all frames.
+ * The filter list is allocated dynamically with the exception of the
+ * list containing only one item.  This common case is optimized by
+ * storing the single filter in dfilter, to avoid using dynamic memory.
+ */
+
+struct raw_sock {
+	struct sock sk;
+	int bound;
+	int ifindex;
+	struct notifier_block notifier;
+	int loopback;
+	int recv_own_msgs;
+	int count;                 /* number of active filters */
+	struct can_filter dfilter; /* default/single filter */
+	struct can_filter *filter; /* pointer to filter(s) */
+	can_err_mask_t err_mask;
+};
+
+static inline struct raw_sock *raw_sk(const struct sock *sk)
+{
+	return (struct raw_sock *)sk;
+}
+
+static void raw_rcv(struct sk_buff *skb, void *data)
+{
+	struct sock *sk = (struct sock *)data;
+	struct raw_sock *ro = raw_sk(sk);
+	struct sockaddr_can *addr;
+	int error;
+
+	DBG("received skbuff %p, sk %p\n", skb, sk);
+	DBG_SKB(skb);
+
+	if (!ro->recv_own_msgs) {
+		/* check the received tx sock reference */
+		if (skb->sk == sk) {
+			DBG("trashed own tx msg\n");
+			kfree_skb(skb);
+			return;
+		}
+	}
+
+	/*
+	 *  Put the datagram to the queue so that raw_recvmsg() can
+	 *  get it from there.  We need to pass the interface index to
+	 *  raw_recvmsg().  We pass a whole struct sockaddr_can in skb->cb
+	 *  containing the interface index.
+	 */
+
+	BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct sockaddr_can));
+	addr = (struct sockaddr_can *)skb->cb;
+	memset(addr, 0, sizeof(*addr));
+	addr->can_family  = AF_CAN;
+	addr->can_ifindex = skb->dev->ifindex;
+
+	error = sock_queue_rcv_skb(sk, skb);
+	if (error < 0) {
+		DBG("sock_queue_rcv_skb failed: %d\n", error);
+		DBG("freeing skbuff %p\n", skb);
+		kfree_skb(skb);
+	}
+}
+
+static int raw_enable_filters(struct net_device *dev, struct sock *sk,
+			      struct can_filter *filter,
+			      int count)
+{
+	int err = 0;
+	int i;
+
+	for (i = 0; i < count; i++) {
+		DBG("filter can_id %08X, can_mask %08X%s, sk %p\n",
+		    filter[i].can_id, filter[i].can_mask,
+		    filter[i].can_id & CAN_INV_FILTER ? " (inv)" : "", sk);
+
+		err = can_rx_register(dev, filter[i].can_id,
+				      filter[i].can_mask,
+				      raw_rcv, sk, IDENT);
+
+		if (err) {
+			/* clean up successfully registered filters */
+			while (--i >= 0)
+				can_rx_unregister(dev, filter[i].can_id,
+						  filter[i].can_mask,
+						  raw_rcv, sk);
+			break;
+		}
+	}
+
+	return err;
+}
+
+static int raw_enable_errfilter(struct net_device *dev, struct sock *sk,
+				can_err_mask_t err_mask)
+{
+	int err = 0;
+
+	if (err_mask)
+		err = can_rx_register(dev, 0, err_mask | CAN_ERR_FLAG,
+				      raw_rcv, sk, IDENT);
+
+	return err;
+}
+
+static void raw_disable_filters(struct net_device *dev, struct sock *sk,
+			      struct can_filter *filter,
+			      int count)
+{
+	int i;
+
+	for (i = 0; i < count; i++) {
+		DBG("filter can_id %08X, can_mask %08X%s, sk %p\n",
+		    filter[i].can_id, filter[i].can_mask,
+		    filter[i].can_id & CAN_INV_FILTER ? " (inv)" : "", sk);
+
+		can_rx_unregister(dev, filter[i].can_id, filter[i].can_mask,
+				  raw_rcv, sk);
+	}
+}
+
+static inline void raw_disable_errfilter(struct net_device *dev,
+					 struct sock *sk,
+					 can_err_mask_t err_mask)
+
+{
+	if (err_mask)
+		can_rx_unregister(dev, 0, err_mask | CAN_ERR_FLAG,
+				  raw_rcv, sk);
+}
+
+static inline void raw_disable_allfilters(struct net_device *dev,
+					  struct sock *sk)
+{
+	struct raw_sock *ro = raw_sk(sk);
+
+	raw_disable_filters(dev, sk, ro->filter, ro->count);
+	raw_disable_errfilter(dev, sk, ro->err_mask);
+}
+
+static int raw_enable_allfilters(struct net_device *dev, struct sock *sk)
+{
+	struct raw_sock *ro = raw_sk(sk);
+	int err;
+
+	err = raw_enable_filters(dev, sk, ro->filter, ro->count);
+	if (!err) {
+		err = raw_enable_errfilter(dev, sk, ro->err_mask);
+		if (err)
+			raw_disable_filters(dev, sk, ro->filter, ro->count);
+	}
+
+	return err;
+}
+
+static int raw_notifier(struct notifier_block *nb,
+			unsigned long msg, void *data)
+{
+	struct net_device *dev = (struct net_device *)data;
+	struct raw_sock *ro = container_of(nb, struct raw_sock, notifier);
+	struct sock *sk = &ro->sk;
+
+	DBG("msg %ld for dev %p (%s idx %d) sk %p ro->ifindex %d\n",
+	    msg, dev, dev->name, dev->ifindex, sk, ro->ifindex);
+
+	if (dev->nd_net != &init_net)
+		return NOTIFY_DONE;
+
+	if (dev->type != ARPHRD_CAN)
+		return NOTIFY_DONE;
+
+	if (ro->ifindex != dev->ifindex)
+		return NOTIFY_DONE;
+
+	switch (msg) {
+
+	case NETDEV_UNREGISTER:
+		lock_sock(sk);
+		/* remove current filters & unregister */
+		if (ro->bound)
+			raw_disable_allfilters(dev, sk);
+
+		if (ro->count > 1)
+			kfree(ro->filter);
+
+		ro->ifindex = 0;
+		ro->bound   = 0;
+		ro->count   = 0;
+		release_sock(sk);
+
+		sk->sk_err = ENODEV;
+		if (!sock_flag(sk, SOCK_DEAD))
+			sk->sk_error_report(sk);
+		break;
+
+	case NETDEV_DOWN:
+		sk->sk_err = ENETDOWN;
+		if (!sock_flag(sk, SOCK_DEAD))
+			sk->sk_error_report(sk);
+		break;
+	}
+
+	return NOTIFY_DONE;
+}
+
+static int raw_init(struct sock *sk)
+{
+	struct raw_sock *ro = raw_sk(sk);
+
+	ro->bound            = 0;
+	ro->ifindex          = 0;
+
+	/* set default filter to single entry dfilter */
+	ro->dfilter.can_id   = 0;
+	ro->dfilter.can_mask = MASK_ALL;
+	ro->filter           = &ro->dfilter;
+	ro->count            = 1;
+
+	/* set default loopback behaviour */
+	ro->loopback         = 1;
+	ro->recv_own_msgs    = 0;
+
+	/* set notifier */
+	ro->notifier.notifier_call = raw_notifier;
+
+	register_netdevice_notifier(&ro->notifier);
+
+	return 0;
+}
+
+static int raw_release(struct socket *sock)
+{
+	struct sock *sk = sock->sk;
+	struct raw_sock *ro = raw_sk(sk);
+
+	DBG("socket %p, sk %p, refcnt %d\n", sock, sk,
+	    atomic_read(&sk->sk_refcnt));
+
+	unregister_netdevice_notifier(&ro->notifier);
+
+	lock_sock(sk);
+
+	/* remove current filters & unregister */
+	if (ro->bound) {
+		if (ro->ifindex) {
+			struct net_device *dev;
+
+			dev = dev_get_by_index(&init_net, ro->ifindex);
+			if (dev) {
+				raw_disable_allfilters(dev, sk);
+				dev_put(dev);
+			}
+		} else
+			raw_disable_allfilters(NULL, sk);
+	}
+
+	if (ro->count > 1)
+		kfree(ro->filter);
+
+	ro->ifindex = 0;
+	ro->bound   = 0;
+	ro->count   = 0;
+
+	release_sock(sk);
+	sock_put(sk);
+
+	return 0;
+}
+
+static int raw_bind(struct socket *sock, struct sockaddr *uaddr, int len)
+{
+	struct sockaddr_can *addr = (struct sockaddr_can *)uaddr;
+	struct sock *sk = sock->sk;
+	struct raw_sock *ro = raw_sk(sk);
+	int ifindex;
+	int err = 0;
+	int notify_enetdown = 0;
+
+	DBG("socket %p to device %d\n", sock, addr->can_ifindex);
+
+	if (len < sizeof(*addr))
+		return -EINVAL;
+
+	lock_sock(sk);
+
+	if (ro->bound && addr->can_ifindex == ro->ifindex)
+		goto out;
+
+	if (addr->can_ifindex) {
+		struct net_device *dev;
+
+		dev = dev_get_by_index(&init_net, addr->can_ifindex);
+		if (!dev) {
+			DBG("could not find device %d\n", addr->can_ifindex);
+			err = -ENODEV;
+			goto out;
+		}
+		if (dev->type != ARPHRD_CAN) {
+			DBG("device %d no CAN device\n", addr->can_ifindex);
+			dev_put(dev);
+			err = -ENODEV;
+			goto out;
+		}
+		if (!(dev->flags & IFF_UP))
+			notify_enetdown = 1;
+
+		ifindex = dev->ifindex;
+
+		/* filters set by default/setsockopt */
+		err = raw_enable_allfilters(dev, sk);
+		dev_put(dev);
+
+	} else {
+		ifindex = 0;
+
+		/* filters set by default/setsockopt */
+		err = raw_enable_allfilters(NULL, sk);
+	}
+
+	if (!err) {
+		if (ro->bound) {
+			/* unregister old filters */
+			if (ro->ifindex) {
+				struct net_device *dev;
+
+				dev = dev_get_by_index(&init_net, ro->ifindex);
+				if (dev) {
+					raw_disable_allfilters(dev, sk);
+					dev_put(dev);
+				}
+			} else
+				raw_disable_allfilters(NULL, sk);
+		}
+		ro->ifindex = ifindex;
+		ro->bound = 1;
+	}
+
+ out:
+	release_sock(sk);
+
+	if (notify_enetdown) {
+		sk->sk_err = ENETDOWN;
+		if (!sock_flag(sk, SOCK_DEAD))
+			sk->sk_error_report(sk);
+	}
+
+	return err;
+}
+
+static int raw_getname(struct socket *sock, struct sockaddr *uaddr,
+		       int *len, int peer)
+{
+	struct sockaddr_can *addr = (struct sockaddr_can *)uaddr;
+	struct sock *sk = sock->sk;
+	struct raw_sock *ro = raw_sk(sk);
+
+	if (peer)
+		return -EOPNOTSUPP;
+
+	addr->can_family  = AF_CAN;
+	addr->can_ifindex = ro->ifindex;
+
+	*len = sizeof(*addr);
+
+	return 0;
+}
+
+static unsigned int raw_poll(struct file *file, struct socket *sock,
+			     poll_table *wait)
+{
+	unsigned int mask = 0;
+
+	DBG("socket %p\n", sock);
+
+	mask = datagram_poll(file, sock, wait);
+	return mask;
+}
+
+static int raw_setsockopt(struct socket *sock, int level, int optname,
+			  char __user *optval, int optlen)
+{
+	struct sock *sk = sock->sk;
+	struct raw_sock *ro = raw_sk(sk);
+	struct can_filter *filter = NULL;  /* dyn. alloc'ed filters */
+	struct can_filter sfilter;         /* single filter */
+	struct net_device *dev = NULL;
+	can_err_mask_t err_mask = 0;
+	int count = 0;
+	int err = 0;
+
+	if (level != SOL_CAN_RAW)
+		return -EINVAL;
+	if (optlen < 0)
+		return -EINVAL;
+
+	switch (optname) {
+
+	case CAN_RAW_FILTER:
+		if (optlen % sizeof(struct can_filter) != 0)
+			return -EINVAL;
+
+		count = optlen / sizeof(struct can_filter);
+
+		if (count > 1) {
+			/* filter does not fit into dfilter => alloc space */
+			filter = kmalloc(optlen, GFP_KERNEL);
+			if (!filter)
+				return -ENOMEM;
+
+			err = copy_from_user(filter, optval, optlen);
+			if (err) {
+				kfree(filter);
+				return err;
+			}
+		} else if (count == 1) {
+			err = copy_from_user(&sfilter, optval, optlen);
+			if (err)
+				return err;
+		}
+
+		lock_sock(sk);
+
+		if (ro->bound && ro->ifindex)
+			dev = dev_get_by_index(&init_net, ro->ifindex);
+
+		if (ro->bound) {
+			/* (try to) register the new filters */
+			if (count == 1)
+				err = raw_enable_filters(dev, sk, &sfilter, 1);
+			else
+				err = raw_enable_filters(dev, sk, filter,
+							 count);
+			if (err) {
+				if (count > 1)
+					kfree(filter);
+
+				goto out_fil;
+			}
+
+			/* remove old filter registrations */
+			raw_disable_filters(dev, sk, ro->filter, ro->count);
+		}
+
+		/* remove old filter space */
+		if (ro->count > 1)
+			kfree(ro->filter);
+
+		/* link new filters to the socket */
+		if (count == 1) {
+			/* copy filter data for single filter */
+			ro->dfilter = sfilter;
+			filter = &ro->dfilter;
+		}
+		ro->filter = filter;
+		ro->count  = count;
+
+ out_fil:
+		if (dev)
+			dev_put(dev);
+
+		release_sock(sk);
+
+		break;
+
+	case CAN_RAW_ERR_FILTER:
+		if (optlen != sizeof(err_mask))
+			return -EINVAL;
+
+		err = copy_from_user(&err_mask, optval, optlen);
+		if (err)
+			return err;
+
+		err_mask &= CAN_ERR_MASK;
+
+		lock_sock(sk);
+
+		if (ro->bound && ro->ifindex)
+			dev = dev_get_by_index(&init_net, ro->ifindex);
+
+		/* remove current error mask */
+		if (ro->bound) {
+			/* (try to) register the new err_mask */
+			err = raw_enable_errfilter(dev, sk, err_mask);
+
+			if (err)
+				goto out_err;
+
+			/* remove old err_mask registration */
+			raw_disable_errfilter(dev, sk, ro->err_mask);
+		}
+
+		/* link new err_mask to the socket */
+		ro->err_mask = err_mask;
+
+ out_err:
+		if (dev)
+			dev_put(dev);
+
+		release_sock(sk);
+
+		break;
+
+	case CAN_RAW_LOOPBACK:
+		if (optlen != sizeof(ro->loopback))
+			return -EINVAL;
+
+		err = copy_from_user(&ro->loopback, optval, optlen);
+
+		break;
+
+	case CAN_RAW_RECV_OWN_MSGS:
+		if (optlen != sizeof(ro->recv_own_msgs))
+			return -EINVAL;
+
+		err = copy_from_user(&ro->recv_own_msgs, optval, optlen);
+
+		break;
+
+	default:
+		return -ENOPROTOOPT;
+	}
+	return err;
+}
+
+static int raw_getsockopt(struct socket *sock, int level, int optname,
+			  char __user *optval, int __user *optlen)
+{
+	struct sock *sk = sock->sk;
+	struct raw_sock *ro = raw_sk(sk);
+	int len;
+	void *val;
+	int err = 0;
+
+	if (level != SOL_CAN_RAW)
+		return -EINVAL;
+	if (get_user(len, optlen))
+		return -EFAULT;
+	if (len < 0)
+		return -EINVAL;
+
+	switch (optname) {
+
+	case CAN_RAW_FILTER:
+		lock_sock(sk);
+		if (ro->count > 0) {
+			int fsize = ro->count * sizeof(struct can_filter);
+			if (len > fsize)
+				len = fsize;
+			err = copy_to_user(optval, ro->filter, len);
+		} else
+			len = 0;
+		release_sock(sk);
+
+		if (!err)
+			err = put_user(len, optlen);
+		return err;
+
+	case CAN_RAW_ERR_FILTER:
+		if (len > sizeof(can_err_mask_t))
+			len = sizeof(can_err_mask_t);
+		val = &ro->err_mask;
+		break;
+
+	case CAN_RAW_LOOPBACK:
+		if (len > sizeof(int))
+			len = sizeof(int);
+		val = &ro->loopback;
+		break;
+
+	case CAN_RAW_RECV_OWN_MSGS:
+		if (len > sizeof(int))
+			len = sizeof(int);
+		val = &ro->recv_own_msgs;
+		break;
+
+	default:
+		return -ENOPROTOOPT;
+	}
+
+	if (put_user(len, optlen))
+		return -EFAULT;
+	if (copy_to_user(optval, val, len))
+		return -EFAULT;
+	return 0;
+}
+
+static int raw_sendmsg(struct kiocb *iocb, struct socket *sock,
+		       struct msghdr *msg, size_t size)
+{
+	struct sock *sk = sock->sk;
+	struct raw_sock *ro = raw_sk(sk);
+	struct sk_buff *skb;
+	struct net_device *dev;
+	int ifindex;
+	int err;
+
+	DBG("socket %p, sk %p\n", sock, sk);
+
+	if (msg->msg_name) {
+		struct sockaddr_can *addr =
+			(struct sockaddr_can *)msg->msg_name;
+
+		if (addr->can_family != AF_CAN)
+			return -EINVAL;
+
+		ifindex = addr->can_ifindex;
+	} else
+		ifindex = ro->ifindex;
+
+	dev = dev_get_by_index(&init_net, ifindex);
+	if (!dev) {
+		DBG("device %d not found\n", ifindex);
+		return -ENXIO;
+	}
+
+	skb = alloc_skb(size, GFP_KERNEL);
+	if (!skb) {
+		dev_put(dev);
+		return -ENOMEM;
+	}
+
+	err = memcpy_fromiovec(skb_put(skb, size), msg->msg_iov, size);
+	if (err < 0) {
+		kfree_skb(skb);
+		dev_put(dev);
+		return err;
+	}
+	skb->dev = dev;
+	skb->sk  = sk;
+
+	DBG("sending skbuff to interface %d\n", ifindex);
+	DBG_SKB(skb);
+
+	err = can_send(skb, ro->loopback);
+
+	dev_put(dev);
+
+	if (err)
+		return err;
+
+	return size;
+}
+
+static int raw_recvmsg(struct kiocb *iocb, struct socket *sock,
+		       struct msghdr *msg, size_t size, int flags)
+{
+	struct sock *sk = sock->sk;
+	struct sk_buff *skb;
+	int error = 0;
+	int noblock;
+
+	DBG("socket %p, sk %p\n", sock, sk);
+
+	noblock =  flags & MSG_DONTWAIT;
+	flags   &= ~MSG_DONTWAIT;
+
+	skb = skb_recv_datagram(sk, flags, noblock, &error);
+	if (!skb)
+		return error;
+
+	DBG("delivering skbuff %p\n", skb);
+	DBG_SKB(skb);
+
+	if (size < skb->len)
+		msg->msg_flags |= MSG_TRUNC;
+	else
+		size = skb->len;
+
+	error = memcpy_toiovec(msg->msg_iov, skb->data, size);
+	if (error < 0) {
+		skb_free_datagram(sk, skb);
+		return error;
+	}
+
+	sock_recv_timestamp(msg, sk, skb);
+
+	if (msg->msg_name) {
+		msg->msg_namelen = sizeof(struct sockaddr_can);
+		memcpy(msg->msg_name, skb->cb, msg->msg_namelen);
+	}
+
+	DBG("freeing sock %p, skbuff %p\n", sk, skb);
+	skb_free_datagram(sk, skb);
+
+	return size;
+}
+
+static struct proto_ops raw_ops __read_mostly = {
+	.family        = PF_CAN,
+	.release       = raw_release,
+	.bind          = raw_bind,
+	.connect       = sock_no_connect,
+	.socketpair    = sock_no_socketpair,
+	.accept        = sock_no_accept,
+	.getname       = raw_getname,
+	.poll          = raw_poll,
+	.ioctl         = NULL,		/* use can_ioctl() from af_can.c */
+	.listen        = sock_no_listen,
+	.shutdown      = sock_no_shutdown,
+	.setsockopt    = raw_setsockopt,
+	.getsockopt    = raw_getsockopt,
+	.sendmsg       = raw_sendmsg,
+	.recvmsg       = raw_recvmsg,
+	.mmap          = sock_no_mmap,
+	.sendpage      = sock_no_sendpage,
+};
+
+static struct proto raw_proto __read_mostly = {
+	.name       = "CAN_RAW",
+	.owner      = THIS_MODULE,
+	.obj_size   = sizeof(struct raw_sock),
+	.init       = raw_init,
+};
+
+static struct can_proto raw_can_proto __read_mostly = {
+	.type       = SOCK_RAW,
+	.protocol   = CAN_RAW,
+	.capability = -1,
+	.ops        = &raw_ops,
+	.prot       = &raw_proto,
+};
+
+static __init int raw_module_init(void)
+{
+	int err;
+
+	printk(banner);
+
+	err = can_proto_register(&raw_can_proto);
+	if (err < 0)
+		printk(KERN_ERR "can: registration of raw protocol failed\n");
+
+	return err;
+}
+
+static __exit void raw_module_exit(void)
+{
+	can_proto_unregister(&raw_can_proto);
+}
+
+module_init(raw_module_init);
+module_exit(raw_module_exit);

--

[PATCH 4/7] CAN: Add broadcast manager (bcm) protocol

[Urs Thuermann]

[-- Attachment #1: 04-can-bcm-proto.diff --]
[-- Type: text/plain, Size: 50108 bytes --]

This patch adds the CAN broadcast manager (bcm) protocol.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 include/linux/can/bcm.h |   65 +
 net/can/Kconfig         |   13 
 net/can/Makefile        |    3 
 net/can/bcm.c           | 1778 ++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 1859 insertions(+)

Index: net-2.6.24/include/linux/can/bcm.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/include/linux/can/bcm.h	2007-09-25 13:31:23.000000000 +0200
@@ -0,0 +1,65 @@
+/*
+ * linux/can/bcm.h
+ *
+ * Definitions for CAN Broadcast Manager (BCM)
+ *
+ * Author: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#ifndef CAN_BCM_H
+#define CAN_BCM_H
+
+/**
+ * struct bcm_msg_head - head of messages to/from the broadcast manager
+ * @opcode:    opcode, see enum below.
+ * @flags:     special flags, see below.
+ * @count:     number of frames to send before changing interval.
+ * @ival1:     interval for the first @count frames.
+ * @ival2:     interval for the following frames.
+ * @can_id:    CAN ID of frames to be sent or received.
+ * @nframes:   number of frames appended to the message head.
+ * @frames:    array of CAN frames.
+ */
+struct bcm_msg_head {
+	int opcode;
+	int flags;
+	int count;
+	struct timeval ival1, ival2;
+	canid_t can_id;
+	int nframes;
+	struct can_frame frames[0];
+};
+
+enum {
+	TX_SETUP = 1,	/* create (cyclic) transmission task */
+	TX_DELETE,	/* remove (cyclic) transmission task */
+	TX_READ,	/* read properties of (cyclic) transmission task */
+	TX_SEND,	/* send one CAN frame */
+	RX_SETUP,	/* create RX content filter subscription */
+	RX_DELETE,	/* remove RX content filter subscription */
+	RX_READ,	/* read properties of RX content filter subscription */
+	TX_STATUS,	/* reply to TX_READ request */
+	TX_EXPIRED,	/* notification on performed transmissions (count=0) */
+	RX_STATUS,	/* reply to RX_READ request */
+	RX_TIMEOUT,	/* cyclic message is absent */
+	RX_CHANGED	/* updated CAN frame (detected content change) */
+};
+
+#define SETTIMER            0x0001
+#define STARTTIMER          0x0002
+#define TX_COUNTEVT         0x0004
+#define TX_ANNOUNCE         0x0008
+#define TX_CP_CAN_ID        0x0010
+#define RX_FILTER_ID        0x0020
+#define RX_CHECK_DLC        0x0040
+#define RX_NO_AUTOTIMER     0x0080
+#define RX_ANNOUNCE_RESUME  0x0100
+#define TX_RESET_MULTI_IDX  0x0200
+#define RX_RTR_FRAME        0x0400
+
+#endif /* CAN_BCM_H */
Index: net-2.6.24/net/can/Kconfig
===================================================================
--- net-2.6.24.orig/net/can/Kconfig	2007-09-25 13:31:06.000000000 +0200
+++ net-2.6.24/net/can/Kconfig	2007-09-25 13:31:46.000000000 +0200
@@ -27,6 +27,19 @@
 	  socket has several filter options e.g. ID-Masking / Errorframes.
 	  To receive/send raw CAN messages, use AF_CAN with protocol CAN_RAW.
 
+config CAN_BCM
+	tristate "Broadcast Manager CAN Protocol (with content filtering)"
+	depends on CAN
+	default N
+	---help---
+	  The Broadcast Manager offers content filtering, timeout monitoring,
+	  sending of RTR-frames and cyclic CAN messages without permanent user
+	  interaction. The BCM can be 'programmed' via the BSD socket API and
+	  informs you on demand e.g. only on content updates / timeouts.
+	  You probably want to use the bcm socket in most cases where cyclic
+	  CAN messages are used on the bus (e.g. in automotive environments).
+	  To use the Broadcast Manager, use AF_CAN with protocol CAN_BCM.
+
 config CAN_DEBUG_CORE
 	bool "CAN Core debugging messages"
 	depends on CAN
Index: net-2.6.24/net/can/Makefile
===================================================================
--- net-2.6.24.orig/net/can/Makefile	2007-09-25 13:29:23.000000000 +0200
+++ net-2.6.24/net/can/Makefile	2007-09-25 13:31:23.000000000 +0200
@@ -7,3 +7,6 @@
 
 obj-$(CONFIG_CAN_RAW)	+= can-raw.o
 can-raw-objs		:= raw.o
+
+obj-$(CONFIG_CAN_BCM)	+= can-bcm.o
+can-bcm-objs		:= bcm.o
Index: net-2.6.24/net/can/bcm.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/net/can/bcm.c	2007-09-25 13:31:23.000000000 +0200
@@ -0,0 +1,1778 @@
+/*
+ * bcm.c - Broadcast Manager to filter/send (cyclic) CAN content
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions, the following disclaimer and
+ *    the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/list.h>
+#include <linux/proc_fs.h>
+#include <linux/uio.h>
+#include <linux/poll.h>
+#include <linux/net.h>
+#include <linux/netdevice.h>
+#include <linux/socket.h>
+#include <linux/if_arp.h>
+#include <linux/skbuff.h>
+#include <linux/can.h>
+#include <linux/can/core.h>
+#include <linux/can/bcm.h>
+#include <net/sock.h>
+#include <net/net_namespace.h>
+
+/* use of last_frames[index].can_dlc */
+#define RX_RECV    0x40 /* received data for this element */
+#define RX_THR     0x80 /* element not been sent due to throttle feature */
+#define BCM_CAN_DLC_MASK 0x0F /* clean private flags in can_dlc by masking */
+
+/* get best masking value for can_rx_register() for a given single can_id */
+#define REGMASK(id) ((id & CAN_RTR_FLAG) | ((id & CAN_EFF_FLAG) ? \
+			(CAN_EFF_MASK | CAN_EFF_FLAG) : CAN_SFF_MASK))
+
+#define IDENT "bcm"
+#define CAN_BCM_VERSION CAN_VERSION
+static __initdata const char banner[] = KERN_INFO
+	"can: broadcast manager protocol (rev " CAN_BCM_VERSION ")\n";
+
+MODULE_DESCRIPTION("PF_CAN broadcast manager protocol");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Oliver Hartkopp <oliver.hartkopp@volkswagen.de>");
+
+#ifdef CONFIG_CAN_DEBUG_CORE
+static int debug;
+module_param(debug, int, S_IRUGO);
+MODULE_PARM_DESC(debug, "debug print mask: 1:debug, 2:frames, 4:skbs");
+#endif
+
+/* easy access to can_frame payload */
+static inline u64 GET_U64(const struct can_frame *cp)
+{
+	return *(u64 *)cp->data;
+}
+
+struct bcm_op {
+	struct list_head list;
+	int ifindex;
+	canid_t can_id;
+	int flags;
+	unsigned long j_ival1, j_ival2, j_lastmsg;
+	unsigned long frames_abs, frames_filtered;
+	struct timer_list timer, thrtimer;
+	struct timeval ival1, ival2;
+	ktime_t rx_stamp;
+	int rx_ifindex;
+	int count;
+	int nframes;
+	int currframe;
+	struct can_frame *frames;
+	struct can_frame *last_frames;
+	struct can_frame sframe;
+	struct can_frame last_sframe;
+	struct sock *sk;
+	struct net_device *rx_reg_dev;
+};
+
+static struct proc_dir_entry *proc_dir;
+
+struct bcm_sock {
+	struct sock sk;
+	int bound;
+	int ifindex;
+	struct notifier_block notifier;
+	struct list_head rx_ops;
+	struct list_head tx_ops;
+	unsigned long dropped_usr_msgs;
+	struct proc_dir_entry *bcm_proc_read;
+	char procname [9]; /* pointer printed in ASCII with \0 */
+};
+
+static inline struct bcm_sock *bcm_sk(const struct sock *sk)
+{
+	return (struct bcm_sock *)sk;
+}
+
+#define CFSIZ sizeof(struct can_frame)
+#define OPSIZ sizeof(struct bcm_op)
+#define MHSIZ sizeof(struct bcm_msg_head)
+
+/*
+ * rounded_tv2jif - calculate jiffies from timeval including optional up
+ * @tv: pointer to timeval
+ *
+ * Description:
+ * Unlike timeval_to_jiffies() provided in include/linux/jiffies.h, this
+ * function is intentionally more relaxed on precise timer ticks to get
+ * exact one jiffy for requested 1000us on a 1000HZ machine.
+ * This code is to be removed when upgrading to kernel hrtimer.
+ *
+ * Return:
+ *  calculated jiffies (max: ULONG_MAX)
+ */
+static unsigned long rounded_tv2jif(const struct timeval *tv)
+{
+	unsigned long sec  = tv->tv_sec;
+	unsigned long usec = tv->tv_usec;
+	unsigned long jif;
+
+	if (sec > ULONG_MAX / HZ)
+		return ULONG_MAX;
+
+	/* round up to get at least the requested time */
+	usec += 1000000 / HZ - 1;
+
+	jif  = usec / (1000000 / HZ);
+
+	if (sec * HZ > ULONG_MAX - jif)
+		return ULONG_MAX;
+
+	return jif + sec * HZ;
+}
+
+/*
+ * procfs functions
+ */
+static char *bcm_proc_getifname(int ifindex)
+{
+	struct net_device *dev;
+
+	if (!ifindex)
+		return "any";
+
+	dev = __dev_get_by_index(&init_net, ifindex); /* no usage counting */
+	if (dev)
+		return dev->name;
+
+	return "???";
+}
+
+static int bcm_read_proc(char *page, char **start, off_t off,
+			 int count, int *eof, void *data)
+{
+	int len = 0;
+	struct sock *sk = (struct sock *)data;
+	struct bcm_sock *bo = bcm_sk(sk);
+	struct bcm_op *op;
+
+	len += snprintf(page + len, PAGE_SIZE - len, ">>> socket %p",
+			sk->sk_socket);
+	len += snprintf(page + len, PAGE_SIZE - len, " / sk %p", sk);
+	len += snprintf(page + len, PAGE_SIZE - len, " / bo %p", bo);
+	len += snprintf(page + len, PAGE_SIZE - len, " / dropped %lu",
+			bo->dropped_usr_msgs);
+	len += snprintf(page + len, PAGE_SIZE - len, " / bound %s",
+			bcm_proc_getifname(bo->ifindex));
+	len += snprintf(page + len, PAGE_SIZE - len, " <<<\n");
+
+	list_for_each_entry(op, &bo->rx_ops, list) {
+
+		unsigned long reduction;
+
+		/* print only active entries & prevent division by zero */
+		if (!op->frames_abs)
+			continue;
+
+		len += snprintf(page + len, PAGE_SIZE - len,
+				"rx_op: %03X %-5s ",
+				op->can_id, bcm_proc_getifname(op->ifindex));
+		len += snprintf(page + len, PAGE_SIZE - len, "[%d]%c ",
+				op->nframes,
+				(op->flags & RX_CHECK_DLC)?'d':' ');
+		if (op->j_ival1)
+			len += snprintf(page + len, PAGE_SIZE - len,
+					"timeo=%ld ", op->j_ival1);
+
+		if (op->j_ival2)
+			len += snprintf(page + len, PAGE_SIZE - len,
+					"thr=%ld ", op->j_ival2);
+
+		len += snprintf(page + len, PAGE_SIZE - len,
+				"# recv %ld (%ld) => reduction: ",
+				op->frames_filtered, op->frames_abs);
+
+		reduction = 100 - (op->frames_filtered * 100) / op->frames_abs;
+
+		len += snprintf(page + len, PAGE_SIZE - len, "%s%ld%%\n",
+				(reduction == 100)?"near ":"", reduction);
+
+		if (len > PAGE_SIZE - 200) {
+			/* mark output cut off */
+			len += snprintf(page + len, PAGE_SIZE - len, "(..)\n");
+			break;
+		}
+	}
+
+	list_for_each_entry(op, &bo->tx_ops, list) {
+
+		len += snprintf(page + len, PAGE_SIZE - len,
+				"tx_op: %03X %s [%d] ",
+				op->can_id, bcm_proc_getifname(op->ifindex),
+				op->nframes);
+		if (op->j_ival1)
+			len += snprintf(page + len, PAGE_SIZE - len, "t1=%ld ",
+					op->j_ival1);
+
+		if (op->j_ival2)
+			len += snprintf(page + len, PAGE_SIZE - len, "t2=%ld ",
+					op->j_ival2);
+
+		len += snprintf(page + len, PAGE_SIZE - len, "# sent %ld\n",
+				op->frames_abs);
+
+		if (len > PAGE_SIZE - 100) {
+			/* mark output cut off */
+			len += snprintf(page + len, PAGE_SIZE - len, "(..)\n");
+			break;
+		}
+	}
+
+	len += snprintf(page + len, PAGE_SIZE - len, "\n");
+
+	*eof = 1;
+	return len;
+}
+
+/*
+ * bcm_can_tx - send the (next) CAN frame to the appropriate CAN interface
+ *              of the given bcm tx op
+ */
+static void bcm_can_tx(struct bcm_op *op)
+{
+	struct sk_buff *skb;
+	struct net_device *dev;
+	struct can_frame *cf = &op->frames[op->currframe];
+
+	DBG_FRAME("BCM: bcm_can_tx: sending frame", cf);
+
+	/* no target device? => exit */
+	if (!op->ifindex)
+		return;
+
+	dev = dev_get_by_index(&init_net, op->ifindex);
+	if (!dev) {
+		/* RFC: should this bcm_op remove itself here? */
+		return;
+	}
+
+	skb = alloc_skb(CFSIZ,
+			in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
+
+	if (!skb)
+		goto out;
+
+	memcpy(skb_put(skb, CFSIZ), cf, CFSIZ);
+
+	/* send with loopback */
+	skb->dev = dev;
+	skb->sk = op->sk;
+	can_send(skb, 1);
+
+	/* update statistics */
+	op->currframe++;
+	op->frames_abs++;
+
+	/* reached last frame? */
+	if (op->currframe >= op->nframes)
+		op->currframe = 0;
+ out:
+	dev_put(dev);
+}
+
+/*
+ * bcm_send_to_user - send a BCM message to the userspace
+ *                    (consisting of bcm_msg_head + x CAN frames)
+ */
+static void bcm_send_to_user(struct bcm_op *op, struct bcm_msg_head *head,
+			     struct can_frame *frames, int has_timestamp)
+{
+	struct sk_buff *skb;
+	struct can_frame *firstframe;
+	struct sockaddr_can *addr;
+	struct sock *sk = op->sk;
+	int datalen = head->nframes * CFSIZ;
+	int err;
+
+	skb = alloc_skb(sizeof(*head) + datalen,
+			in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
+	if (!skb)
+		return;
+
+	memcpy(skb_put(skb, sizeof(*head)), head, sizeof(*head));
+
+	if (head->nframes) {
+		/* can_frames starting here */
+		firstframe = (struct can_frame *) skb_tail_pointer(skb);
+
+		memcpy(skb_put(skb, datalen), frames, datalen);
+
+		/*
+		 * the BCM uses the can_dlc-element of the can_frame
+		 * structure for internal purposes. This is only
+		 * relevant for updates that are generated by the
+		 * BCM, where nframes is 1
+		 */
+		if (head->nframes == 1)
+			firstframe->can_dlc &= BCM_CAN_DLC_MASK;
+	}
+
+	if (has_timestamp) {
+		/* restore rx timestamp */
+		skb->tstamp = op->rx_stamp;
+	}
+
+	/*
+	 *  Put the datagram to the queue so that bcm_recvmsg() can
+	 *  get it from there.  We need to pass the interface index to
+	 *  bcm_recvmsg().  We pass a whole struct sockaddr_can in skb->cb
+	 *  containing the interface index.
+	 */
+
+	BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct sockaddr_can));
+	addr = (struct sockaddr_can *)skb->cb;
+	memset(addr, 0, sizeof(*addr));
+	addr->can_family  = AF_CAN;
+	addr->can_ifindex = op->rx_ifindex;
+
+	err = sock_queue_rcv_skb(sk, skb);
+	if (err < 0) {
+		struct bcm_sock *bo = bcm_sk(sk);
+
+		DBG("sock_queue_rcv_skb failed: %d\n", err);
+		kfree_skb(skb);
+		/* don't care about overflows in this statistic */
+		bo->dropped_usr_msgs++;
+	}
+}
+
+/*
+ * bcm_tx_timeout_handler - performes cyclic CAN frame transmissions
+ */
+static void bcm_tx_timeout_handler(unsigned long data)
+{
+	struct bcm_op *op = (struct bcm_op *)data;
+
+	DBG("Called with bcm_op %p\n", op);
+
+	if (op->j_ival1 && (op->count > 0)) {
+
+		op->count--;
+		if (!op->count && (op->flags & TX_COUNTEVT)) {
+			struct bcm_msg_head msg_head;
+
+			/* create notification to user */
+			DBG("sending TX_EXPIRED for can_id %03X\n",
+			    op->can_id);
+
+			msg_head.opcode  = TX_EXPIRED;
+			msg_head.flags   = op->flags;
+			msg_head.count   = op->count;
+			msg_head.ival1   = op->ival1;
+			msg_head.ival2   = op->ival2;
+			msg_head.can_id  = op->can_id;
+			msg_head.nframes = 0;
+
+			bcm_send_to_user(op, &msg_head, NULL, 0);
+		}
+	}
+
+	DBG("count=%d j_ival1=%ld j_ival2=%ld\n",
+	    op->count, op->j_ival1, op->j_ival2);
+
+	if (op->j_ival1 && (op->count > 0)) {
+
+		op->timer.expires = jiffies + op->j_ival1;
+		add_timer(&op->timer);
+
+		DBG("adding timer ival1. func=%p data=%p exp=0x%08X\n",
+		    op->timer.function,
+		    (char *) op->timer.data,
+		    (unsigned int) op->timer.expires);
+
+		/* send (next) frame */
+		bcm_can_tx(op);
+
+	} else {
+		if (op->j_ival2) {
+			op->timer.expires = jiffies + op->j_ival2;
+			add_timer(&op->timer);
+
+			DBG("adding timer ival2. func=%p data=%p exp=0x%08X\n",
+			    op->timer.function,
+			    (char *) op->timer.data,
+			    (unsigned int) op->timer.expires);
+
+			/* send (next) frame */
+			bcm_can_tx(op);
+
+		} else
+			DBG("no timer restart\n");
+	}
+
+	return;
+}
+
+/*
+ * bcm_rx_changed - create a RX_CHANGED notification due to changed content
+ */
+static void bcm_rx_changed(struct bcm_op *op, struct can_frame *data)
+{
+	struct bcm_msg_head head;
+
+	op->j_lastmsg = jiffies;
+
+	/* update statistics */
+	op->frames_filtered++;
+
+	/* prevent statistics overflow */
+	if (op->frames_filtered > ULONG_MAX/100)
+		op->frames_filtered = op->frames_abs = 0;
+
+	DBG("setting j_lastmsg to 0x%08X for rx_op %p\n",
+	    (unsigned int) op->j_lastmsg, op);
+	DBG("sending notification\n");
+
+	head.opcode  = RX_CHANGED;
+	head.flags   = op->flags;
+	head.count   = op->count;
+	head.ival1   = op->ival1;
+	head.ival2   = op->ival2;
+	head.can_id  = op->can_id;
+	head.nframes = 1;
+
+	bcm_send_to_user(op, &head, data, 1);
+}
+
+/*
+ * bcm_rx_update_and_send - process a detected relevant receive content change
+ *                          1. update the last received data
+ *                          2. send a notification to the user (if possible)
+ */
+static void bcm_rx_update_and_send(struct bcm_op *op,
+				   struct can_frame *lastdata,
+				   struct can_frame *rxdata)
+{
+	unsigned long nexttx = op->j_lastmsg + op->j_ival2;
+
+	memcpy(lastdata, rxdata, CFSIZ);
+
+	/* mark as used */
+	lastdata->can_dlc |= RX_RECV;
+
+	/* throttle bcm_rx_changed ? */
+	if ((op->thrtimer.expires) ||
+	    ((op->j_ival2) && (nexttx > jiffies))) {
+		/* we are already waiting OR we have to start waiting */
+
+		/* mark as 'throttled' */
+		lastdata->can_dlc |= RX_THR;
+
+		if (!(op->thrtimer.expires)) {
+			/* start the timer only the first time */
+			op->thrtimer.expires = nexttx;
+			add_timer(&op->thrtimer);
+
+			DBG("adding thrtimer. func=%p data=%p exp=0x%08X\n",
+			    op->thrtimer.function,
+			    (char *) op->thrtimer.data,
+			    (unsigned int) op->thrtimer.expires);
+		}
+
+	} else {
+		/* send RX_CHANGED to the user immediately */
+		bcm_rx_changed(op, rxdata);
+	}
+}
+
+/*
+ * bcm_rx_cmp_to_index - (bit)compares the currently received data to formerly
+ *                       received data stored in op->last_frames[]
+ */
+static void bcm_rx_cmp_to_index(struct bcm_op *op, int index,
+				struct can_frame *rxdata)
+{
+	/*
+	 * no one uses the MSBs of can_dlc for comparation,
+	 * so we use it here to detect the first time of reception
+	 */
+
+	if (!(op->last_frames[index].can_dlc & RX_RECV)) {
+		/* received data for the first time => send update to user */
+		DBG("first time :)\n");
+		bcm_rx_update_and_send(op, &op->last_frames[index], rxdata);
+		return;
+	}
+
+	/* do a real check in can_frame data section */
+
+	DBG("op->frames[index].data = 0x%016llx\n",
+	    GET_U64(&op->frames[index]));
+	DBG("op->last_frames[index].data = 0x%016llx\n",
+	    GET_U64(&op->last_frames[index]));
+	DBG("rxdata->data = 0x%016llx\n", GET_U64(rxdata));
+
+	if ((GET_U64(&op->frames[index]) & GET_U64(rxdata)) !=
+	    (GET_U64(&op->frames[index]) & GET_U64(&op->last_frames[index]))) {
+		DBG("relevant data change :)\n");
+		bcm_rx_update_and_send(op, &op->last_frames[index], rxdata);
+		return;
+	}
+
+	if (op->flags & RX_CHECK_DLC) {
+		/* do a real check in can_frame dlc */
+		if (rxdata->can_dlc != (op->last_frames[index].can_dlc &
+					BCM_CAN_DLC_MASK)) {
+			DBG("dlc change :)\n");
+			bcm_rx_update_and_send(op, &op->last_frames[index],
+					       rxdata);
+			return;
+		}
+	}
+	DBG("no relevant change :(\n");
+}
+
+/*
+ * bcm_rx_starttimer - enable timeout monitoring for CAN frame receiption
+ */
+static void bcm_rx_starttimer(struct bcm_op *op)
+{
+	if (op->flags & RX_NO_AUTOTIMER)
+		return;
+
+	if (op->j_ival1) {
+		op->timer.expires = jiffies + op->j_ival1;
+
+		DBG("adding rx timeout timer ival1. func=%p data=%p "
+		    "exp=0x%08X\n",
+		    op->timer.function,
+		    (char *) op->timer.data,
+		    (unsigned int) op->timer.expires);
+
+		add_timer(&op->timer);
+	}
+}
+
+/*
+ * bcm_rx_timeout_handler - when the (cyclic) CAN frame receiption timed out
+ */
+static void bcm_rx_timeout_handler(unsigned long data)
+{
+	struct bcm_op *op = (struct bcm_op *)data;
+	struct bcm_msg_head msg_head;
+
+	DBG("sending RX_TIMEOUT for can_id %03X. op is %p\n", op->can_id, op);
+
+	msg_head.opcode  = RX_TIMEOUT;
+	msg_head.flags   = op->flags;
+	msg_head.count   = op->count;
+	msg_head.ival1   = op->ival1;
+	msg_head.ival2   = op->ival2;
+	msg_head.can_id  = op->can_id;
+	msg_head.nframes = 0;
+
+	bcm_send_to_user(op, &msg_head, NULL, 0);
+
+	/* no restart of the timer is done here! */
+
+	/* if user wants to be informed, when cyclic CAN-Messages come back */
+	if ((op->flags & RX_ANNOUNCE_RESUME) && op->last_frames) {
+		/* clear received can_frames to indicate 'nothing received' */
+		memset(op->last_frames, 0, op->nframes * CFSIZ);
+		DBG("RX_ANNOUNCE_RESTART\n");
+	}
+}
+
+/*
+ * bcm_rx_thr_handler - the time for blocked content updates is over now:
+ *                      Check for throttled data and send it to the userspace
+ */
+static void bcm_rx_thr_handler(unsigned long data)
+{
+	struct bcm_op *op = (struct bcm_op *)data;
+	int i = 0;
+
+	/* mark disabled / consumed timer */
+	op->thrtimer.expires = 0;
+
+	if (op->nframes > 1) {
+		DBG("sending MUX RX_CHANGED for can_id %03X. op is %p\n",
+		    op->can_id, op);
+		/* for MUX filter we start at index 1 */
+		for (i = 1; i < op->nframes; i++) {
+			if ((op->last_frames) &&
+			    (op->last_frames[i].can_dlc & RX_THR)) {
+				op->last_frames[i].can_dlc &= ~RX_THR;
+				bcm_rx_changed(op, &op->last_frames[i]);
+			}
+		}
+
+	} else {
+		DBG("sending simple RX_CHANGED for can_id %03X. op is %p\n",
+		    op->can_id, op);
+		/* for RX_FILTER_ID and simple filter */
+		if (op->last_frames && (op->last_frames[0].can_dlc & RX_THR)) {
+			op->last_frames[0].can_dlc &= ~RX_THR;
+			bcm_rx_changed(op, &op->last_frames[0]);
+		}
+	}
+}
+
+/*
+ * bcm_rx_handler - handle a CAN frame receiption
+ */
+static void bcm_rx_handler(struct sk_buff *skb, void *data)
+{
+	struct bcm_op *op = (struct bcm_op *)data;
+	struct can_frame rxframe;
+	int i;
+
+	/* disable timeout */
+	del_timer(&op->timer);
+
+	DBG("Called with bcm_op %p\n", op);
+
+	if (skb->len == sizeof(rxframe)) {
+		memcpy(&rxframe, skb->data, sizeof(rxframe));
+		/* save rx timestamp */
+		op->rx_stamp = skb->tstamp;
+		/* save originator for recvfrom() */
+		op->rx_ifindex = skb->dev->ifindex;
+		/* update statistics */
+		op->frames_abs++;
+		kfree_skb(skb);
+		DBG("got can_frame with can_id %03X\n", rxframe.can_id);
+
+	} else {
+		DBG("Wrong skb->len = %d\n", skb->len);
+		kfree_skb(skb);
+		return;
+	}
+
+	DBG_FRAME("BCM: bcm_rx_handler: CAN frame", &rxframe);
+
+	if (op->can_id != rxframe.can_id) {
+		DBG("ERROR! Got wrong can_id %03X! Expected %03X.\n",
+		    rxframe.can_id, op->can_id);
+		return;
+	}
+
+	if (op->flags & RX_RTR_FRAME) {
+		/* send reply for RTR-request */
+		DBG("RTR-request\n");
+
+		/* send op->frames[0] to CAN device */
+		bcm_can_tx(op);
+		return;
+	}
+
+	if (op->flags & RX_FILTER_ID) {
+		/* the easiest case */
+		DBG("Easy does it with RX_FILTER_ID\n");
+
+		bcm_rx_update_and_send(op, &op->last_frames[0], &rxframe);
+		bcm_rx_starttimer(op);
+		return;
+	}
+
+	if (op->nframes == 1) {
+		/* simple compare with index 0 */
+		DBG("Simple compare\n");
+
+		bcm_rx_cmp_to_index(op, 0, &rxframe);
+		bcm_rx_starttimer(op);
+		return;
+	}
+
+	if (op->nframes > 1) {
+		/* multiplex compare */
+		DBG("Multiplex compare\n");
+
+		/*
+		 * find the first multiplex mask that fits.
+		 * Remark: The MUX-mask is stored in index 0
+		 */
+
+		for (i = 1; i < op->nframes; i++) {
+			if ((GET_U64(&op->frames[0]) & GET_U64(&rxframe)) ==
+			    (GET_U64(&op->frames[0]) &
+			     GET_U64(&op->frames[i]))) {
+				DBG("found MUX index %d\n", i);
+				bcm_rx_cmp_to_index(op, i, &rxframe);
+				break;
+			}
+		}
+		bcm_rx_starttimer(op);
+	}
+}
+
+/*
+ * helpers for bcm_op handling: find & delete bcm [rx|tx] op elements
+ */
+static struct bcm_op *bcm_find_op(struct list_head *ops, canid_t can_id,
+				  int ifindex)
+{
+	struct bcm_op *op;
+
+	list_for_each_entry(op, ops, list) {
+		if ((op->can_id == can_id) && (op->ifindex == ifindex))
+			return op;
+	}
+
+	return NULL;
+}
+
+static void bcm_remove_op(struct bcm_op *op)
+{
+	del_timer(&op->timer);
+	del_timer(&op->thrtimer);
+
+	if ((op->frames) && (op->frames != &op->sframe))
+		kfree(op->frames);
+
+	if ((op->last_frames) && (op->last_frames != &op->last_sframe))
+		kfree(op->last_frames);
+
+	kfree(op);
+
+	return;
+}
+
+static void bcm_rx_unreg(struct net_device *dev, struct bcm_op *op)
+{
+	if (op->rx_reg_dev == dev) {
+		can_rx_unregister(dev, op->can_id, REGMASK(op->can_id),
+				  bcm_rx_handler, op);
+
+		/* mark as removed subscription */
+		op->rx_reg_dev = NULL;
+	} else
+		printk(KERN_ERR "can-bcm: bcm_rx_unreg: registered device "
+		       "mismatch %p %p\n", op->rx_reg_dev, dev);
+}
+
+/*
+ * bcm_delete_rx_op - find and remove a rx op (returns number of removed ops)
+ */
+static int bcm_delete_rx_op(struct list_head *ops, canid_t can_id, int ifindex)
+{
+	struct bcm_op *op, *n;
+
+	list_for_each_entry_safe(op, n, ops, list) {
+		if ((op->can_id == can_id) && (op->ifindex == ifindex)) {
+			DBG("removing rx_op %p for can_id %03X\n",
+			    op, op->can_id);
+
+			/*
+			 * Don't care if we're bound or not (due to netdev
+			 * problems) can_rx_unregister() is always a save
+			 * thing to do here.
+			 */
+			if (op->ifindex) {
+				/*
+				 * Only remove subscriptions that had not
+				 * been removed due to NETDEV_UNREGISTER
+				 * in bcm_notifier()
+				 */
+				if (op->rx_reg_dev) {
+					struct net_device *dev;
+
+					dev = dev_get_by_index(&init_net,
+							       op->ifindex);
+					if (dev) {
+						bcm_rx_unreg(dev, op);
+						dev_put(dev);
+					}
+				}
+			} else
+				can_rx_unregister(NULL, op->can_id,
+						  REGMASK(op->can_id),
+						  bcm_rx_handler, op);
+
+			list_del(&op->list);
+			bcm_remove_op(op);
+			return 1; /* done */
+		}
+	}
+
+	return 0; /* not found */
+}
+
+/*
+ * bcm_delete_tx_op - find and remove a tx op (returns number of removed ops)
+ */
+static int bcm_delete_tx_op(struct list_head *ops, canid_t can_id, int ifindex)
+{
+	struct bcm_op *op, *n;
+
+	list_for_each_entry_safe(op, n, ops, list) {
+		if ((op->can_id == can_id) && (op->ifindex == ifindex)) {
+			DBG("removing rx_op %p for can_id %03X\n",
+			    op, op->can_id);
+			list_del(&op->list);
+			bcm_remove_op(op);
+			return 1; /* done */
+		}
+	}
+
+	return 0; /* not found */
+}
+
+/*
+ * bcm_read_op - read out a bcm_op and send it to the user (for bcm_sendmsg)
+ */
+static int bcm_read_op(struct list_head *ops, struct bcm_msg_head *msg_head,
+		       int ifindex)
+{
+	struct bcm_op *op = bcm_find_op(ops, msg_head->can_id, ifindex);
+
+	if (!op) {
+		DBG("TRX_READ: did not find op for can_id %03X\n",
+		    msg_head->can_id);
+		return -EINVAL;
+	}
+
+	DBG("TRX_READ: sending status for can_id %03X\n",
+	    msg_head->can_id);
+	/* put current values into msg_head */
+	msg_head->flags   = op->flags;
+	msg_head->count   = op->count;
+	msg_head->ival1   = op->ival1;
+	msg_head->ival2   = op->ival2;
+	msg_head->nframes = op->nframes;
+
+	bcm_send_to_user(op, msg_head, op->frames, 0);
+
+	return MHSIZ;
+}
+
+/*
+ * bcm_tx_setup - create or update a bcm tx op (for bcm_sendmsg)
+ */
+static int bcm_tx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
+			int ifindex, struct sock *sk)
+{
+	struct bcm_sock *bo = bcm_sk(sk);
+	struct bcm_op *op;
+	int i, err;
+
+	/* we need a real device to send frames */
+	if (!ifindex)
+		return -ENODEV;
+
+	/* we need at least one can_frame */
+	if (msg_head->nframes < 1)
+		return -EINVAL;
+
+	/* check the given can_id */
+	op = bcm_find_op(&bo->tx_ops, msg_head->can_id, ifindex);
+
+	if (op) {
+		/* update existing BCM operation */
+
+		DBG("TX_SETUP: modifying existing tx_op %p for can_id %03X\n",
+		    op, msg_head->can_id);
+
+		/*
+		 * Do we need more space for the can_frames than currently
+		 * allocated? -> This is a _really_ unusual use-case and
+		 * therefore (complexity / locking) it is not supported.
+		 */
+		if (msg_head->nframes > op->nframes)
+			return -E2BIG;
+
+		/* update can_frames content */
+		for (i = 0; i < msg_head->nframes; i++) {
+			err = memcpy_fromiovec((u8 *)&op->frames[i],
+					       msg->msg_iov, CFSIZ);
+			if (err < 0)
+				return err;
+
+			if (msg_head->flags & TX_CP_CAN_ID) {
+				/* copy can_id into frame */
+				op->frames[i].can_id = msg_head->can_id;
+			}
+		}
+
+	} else {
+		/* insert new BCM operation for the given can_id */
+
+		op = kzalloc(OPSIZ, GFP_KERNEL);
+		if (!op)
+			return -ENOMEM;
+
+		DBG("TX_SETUP: creating new tx_op %p for can_id %03X\n",
+		    op, msg_head->can_id);
+
+		op->can_id    = msg_head->can_id;
+
+		/* create array for can_frames and copy the data */
+		if (msg_head->nframes > 1) {
+			op->frames = kmalloc(msg_head->nframes * CFSIZ,
+					     GFP_KERNEL);
+			if (!op->frames) {
+				kfree(op);
+				return -ENOMEM;
+			}
+		} else
+			op->frames = &op->sframe;
+
+		for (i = 0; i < msg_head->nframes; i++) {
+			err = memcpy_fromiovec((u8 *)&op->frames[i],
+					       msg->msg_iov, CFSIZ);
+			if (err < 0) {
+				if (op->frames != &op->sframe)
+					kfree(op->frames);
+				kfree(op);
+				return err;
+			}
+
+			if (msg_head->flags & TX_CP_CAN_ID) {
+				/* copy can_id into frame */
+				op->frames[i].can_id = msg_head->can_id;
+			}
+		}
+
+		/* tx_ops never compare with previous received messages */
+		op->last_frames = NULL;
+
+		/* bcm_can_tx / bcm_tx_timeout_handler needs this */
+		op->sk = sk;
+
+		op->ifindex = ifindex;
+
+		/* initialize uninitialized (kmalloc) structure */
+		init_timer(&op->timer);
+
+		/* currently unused in tx_ops */
+		init_timer(&op->thrtimer);
+
+		/* handler for tx_ops */
+		op->timer.function = bcm_tx_timeout_handler;
+
+		/* timer.data points to this op-structure */
+		op->timer.data = (unsigned long)op;
+
+		/* add this bcm_op to the list of the tx_ops */
+		list_add(&op->list, &bo->tx_ops);
+
+	} /* if ((op = bcm_find_op(&bo->tx_ops, msg_head->can_id, ifindex))) */
+
+	if (op->nframes != msg_head->nframes) {
+		op->nframes   = msg_head->nframes;
+		/* start multiple frame transmission with index 0 */
+		op->currframe = 0;
+	}
+
+	/* check flags */
+
+	op->flags = msg_head->flags;
+
+	if (op->flags & TX_RESET_MULTI_IDX) {
+		/* start multiple frame transmission with index 0 */
+		op->currframe = 0;
+	}
+
+	if (op->flags & SETTIMER) {
+		/* set timer values */
+
+		op->count = msg_head->count;
+		op->ival1 = msg_head->ival1;
+		op->ival2 = msg_head->ival2;
+		op->j_ival1 = rounded_tv2jif(&msg_head->ival1);
+		op->j_ival2 = rounded_tv2jif(&msg_head->ival2);
+
+		DBG("TX_SETUP: SETTIMER count=%d j_ival1=%ld j_ival2=%ld\n",
+		    op->count, op->j_ival1, op->j_ival2);
+
+		/* disable an active timer due to zero values? */
+		if (!op->j_ival1 && !op->j_ival2) {
+			del_timer(&op->timer);
+			DBG("TX_SETUP: SETTIMER disabled timer.\n");
+		}
+	}
+
+	if ((op->flags & STARTTIMER) &&
+	    ((op->j_ival1 && op->count) || op->j_ival2)) {
+
+		del_timer(&op->timer);
+
+		/* spec: send can_frame when starting timer */
+		op->flags |= TX_ANNOUNCE;
+
+		if (op->j_ival1 && (op->count > 0)) {
+			op->timer.expires = jiffies + op->j_ival1;
+			/* op->count-- is done in bcm_tx_timeout_handler */
+			DBG("TX_SETUP: adding timer ival1. func=%p data=%p "
+			    "exp=0x%08X\n",
+			    op->timer.function,
+			    (char *) op->timer.data,
+			    (unsigned int) op->timer.expires);
+
+		} else {
+			op->timer.expires = jiffies + op->j_ival2;
+			DBG("TX_SETUP: adding timer ival2. func=%p data=%p "
+			    "exp=0x%08X\n",
+			    op->timer.function,
+			    (char *) op->timer.data,
+			    (unsigned int) op->timer.expires);
+		}
+
+		add_timer(&op->timer);
+	}
+
+	if (op->flags & TX_ANNOUNCE)
+		bcm_can_tx(op);
+
+	return msg_head->nframes * CFSIZ + MHSIZ;
+}
+
+/*
+ * bcm_rx_setup - create or update a bcm rx op (for bcm_sendmsg)
+ */
+static int bcm_rx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,
+			int ifindex, struct sock *sk)
+{
+	struct bcm_sock *bo = bcm_sk(sk);
+	struct bcm_op *op;
+	int do_rx_register;
+	int err = 0;
+
+	if ((msg_head->flags & RX_FILTER_ID) || (!(msg_head->nframes))) {
+		/* be robust against wrong usage ... */
+		msg_head->flags |= RX_FILTER_ID;
+		msg_head->nframes = 0; /* ignore trailing garbage */
+	}
+
+	if ((msg_head->flags & RX_RTR_FRAME) &&
+	    ((msg_head->nframes != 1) ||
+	     (!(msg_head->can_id & CAN_RTR_FLAG)))) {
+
+		DBG("RX_SETUP: bad RX_RTR_FRAME setup!\n");
+		return -EINVAL;
+	}
+
+	/* check the given can_id */
+	op = bcm_find_op(&bo->rx_ops, msg_head->can_id, ifindex);
+	if (op) {
+		/* update existing BCM operation */
+
+		DBG("RX_SETUP: modifying existing rx_op %p for can_id %03X\n",
+		    op, msg_head->can_id);
+
+		/*
+		 * Do we need more space for the can_frames than currently
+		 * allocated? -> This is a _really_ unusual use-case and
+		 * therefore (complexity / locking) it is not supported.
+		 */
+		if (msg_head->nframes > op->nframes)
+			return -E2BIG;
+
+		if (msg_head->nframes) {
+			/* update can_frames content */
+			err = memcpy_fromiovec((u8 *)op->frames,
+					       msg->msg_iov,
+					       msg_head->nframes * CFSIZ);
+			if (err < 0)
+				return err;
+
+			/* clear last_frames to indicate 'nothing received' */
+			memset(op->last_frames, 0, msg_head->nframes * CFSIZ);
+		}
+
+		op->nframes = msg_head->nframes;
+
+		/* Only an update -> do not call can_rx_register() */
+		do_rx_register = 0;
+
+	} else {
+		/* insert new BCM operation for the given can_id */
+
+		op = kzalloc(OPSIZ, GFP_KERNEL);
+		if (!op)
+			return -ENOMEM;
+
+		DBG("RX_SETUP: creating new rx_op %p for can_id %03X\n",
+		    op, msg_head->can_id);
+
+		op->can_id    = msg_head->can_id;
+		op->nframes   = msg_head->nframes;
+
+		if (msg_head->nframes > 1) {
+			/* create array for can_frames and copy the data */
+			op->frames = kmalloc(msg_head->nframes * CFSIZ,
+					     GFP_KERNEL);
+			if (!op->frames) {
+				kfree(op);
+				return -ENOMEM;
+			}
+
+			/* create and init array for received can_frames */
+			op->last_frames = kzalloc(msg_head->nframes * CFSIZ,
+						  GFP_KERNEL);
+			if (!op->last_frames) {
+				kfree(op->frames);
+				kfree(op);
+				return -ENOMEM;
+			}
+
+		} else {
+			op->frames = &op->sframe;
+			op->last_frames = &op->last_sframe;
+		}
+
+		if (msg_head->nframes) {
+			err = memcpy_fromiovec((u8 *)op->frames, msg->msg_iov,
+					       msg_head->nframes * CFSIZ);
+			if (err < 0) {
+				if (op->frames != &op->sframe)
+					kfree(op->frames);
+				if (op->last_frames != &op->last_sframe)
+					kfree(op->last_frames);
+				kfree(op);
+				return err;
+			}
+		}
+
+		op->sk = sk;
+		op->ifindex = ifindex;
+
+		/* initialize uninitialized (kzalloc) structure */
+		init_timer(&op->timer);
+
+		/* init throttle timer for RX_CHANGED */
+		init_timer(&op->thrtimer);
+
+		/* handler for rx timeouts */
+		op->timer.function = bcm_rx_timeout_handler;
+
+		/* timer.data points to this op-structure */
+		op->timer.data = (unsigned long)op;
+
+		/* handler for RX_CHANGED throttle timeouts */
+		op->thrtimer.function = bcm_rx_thr_handler;
+
+		/* timer.data points to this op-structure */
+		op->thrtimer.data = (unsigned long)op;
+
+		/* mark disabled timer */
+		op->thrtimer.expires = 0;
+
+		/* add this bcm_op to the list of the rx_ops */
+		list_add(&op->list, &bo->rx_ops);
+
+		/* call can_rx_register() */
+		do_rx_register = 1;
+
+	} /* if ((op = bcm_find_op(&bo->rx_ops, msg_head->can_id, ifindex))) */
+
+	/* check flags */
+	op->flags = msg_head->flags;
+
+	if (op->flags & RX_RTR_FRAME) {
+
+		/* no timers in RTR-mode */
+		del_timer(&op->thrtimer);
+		del_timer(&op->timer);
+
+		/*
+		 * funny feature in RX(!)_SETUP only for RTR-mode:
+		 * copy can_id into frame BUT without RTR-flag to
+		 * prevent a full-load-loopback-test ... ;-]
+		 */
+		if ((op->flags & TX_CP_CAN_ID) ||
+		    (op->frames[0].can_id == op->can_id))
+			op->frames[0].can_id = op->can_id & ~CAN_RTR_FLAG;
+
+	} else {
+		if (op->flags & SETTIMER) {
+
+			/* set timer value */
+			op->ival1 = msg_head->ival1;
+			op->ival2 = msg_head->ival2;
+			op->j_ival1 = rounded_tv2jif(&msg_head->ival1);
+			op->j_ival2 = rounded_tv2jif(&msg_head->ival2);
+
+			DBG("RX_SETUP: SETTIMER j_ival1=%ld j_ival2=%ld\n",
+			    op->j_ival1, op->j_ival2);
+
+			/* disable an active timer due to zero value? */
+			if (!op->j_ival1) {
+				del_timer(&op->timer);
+				DBG("RX_SETUP: disabled timer rx timeouts.\n");
+			}
+
+			/* free currently blocked msgs ? */
+			if (op->thrtimer.expires) {
+				DBG("RX_SETUP: unblocking throttled msgs.\n");
+				del_timer(&op->thrtimer);
+				/* send blocked msgs hereafter */
+				op->thrtimer.expires = jiffies + 2;
+				add_timer(&op->thrtimer);
+			}
+			/*
+			 * if (op->j_ival2) is zero, no (new) throttling
+			 * will happen. For details see functions
+			 * bcm_rx_update_and_send() and bcm_rx_thr_handler()
+			 */
+		}
+
+		if ((op->flags & STARTTIMER) && op->j_ival1) {
+
+			del_timer(&op->timer);
+			op->timer.expires = jiffies + op->j_ival1;
+
+			DBG("RX_SETUP: adding timer ival1. func=%p data=%p"
+			    " exp=0x%08X\n",
+			    (char *) op->timer.function,
+			    (char *) op->timer.data,
+			    (unsigned int) op->timer.expires);
+
+			add_timer(&op->timer);
+		}
+	}
+
+	/* now we can register for can_ids, if we added a new bcm_op */
+	if (do_rx_register) {
+		DBG("RX_SETUP: can_rx_register() for can_id %03X. "
+		    "rx_op is %p\n", op->can_id, op);
+
+		if (ifindex) {
+			struct net_device *dev;
+
+			dev = dev_get_by_index(&init_net, ifindex);
+			if (dev) {
+				err = can_rx_register(dev, op->can_id,
+						      REGMASK(op->can_id),
+						      bcm_rx_handler, op,
+						      IDENT);
+
+				op->rx_reg_dev = dev;
+				dev_put(dev);
+			}
+
+		} else
+			err = can_rx_register(NULL, op->can_id,
+					      REGMASK(op->can_id),
+					      bcm_rx_handler, op, IDENT);
+		if (err) {
+			/* this bcm rx op is broken -> remove it */
+			list_del(&op->list);
+			bcm_remove_op(op);
+			return err;
+		}
+	}
+
+	return msg_head->nframes * CFSIZ + MHSIZ;
+}
+
+/*
+ * bcm_tx_send - send a single CAN frame to the CAN interface (for bcm_sendmsg)
+ */
+static int bcm_tx_send(struct msghdr *msg, int ifindex, struct sock *sk)
+{
+	struct sk_buff *skb;
+	struct net_device *dev;
+	int err;
+
+	/* just copy and send one can_frame */
+
+	if (!ifindex) /* we need a real device to send frames */
+		return -ENODEV;
+
+	skb = alloc_skb(CFSIZ, GFP_KERNEL);
+
+	if (!skb)
+		return -ENOMEM;
+
+	err = memcpy_fromiovec(skb_put(skb, CFSIZ), msg->msg_iov, CFSIZ);
+	if (err < 0) {
+		kfree_skb(skb);
+		return err;
+	}
+
+	DBG_FRAME("BCM: TX_SEND: sending frame",
+		  (struct can_frame *)skb->data);
+
+	dev = dev_get_by_index(&init_net, ifindex);
+	if (!dev) {
+		kfree_skb(skb);
+		return -ENODEV;
+	}
+
+	skb->dev = dev;
+	skb->sk  = sk;
+	can_send(skb, 1); /* send with loopback */
+	dev_put(dev);
+
+	return CFSIZ + MHSIZ;
+}
+
+/*
+ * bcm_sendmsg - process BCM commands (opcodes) from the userspace
+ */
+static int bcm_sendmsg(struct kiocb *iocb, struct socket *sock,
+		       struct msghdr *msg, size_t size)
+{
+	struct sock *sk = sock->sk;
+	struct bcm_sock *bo = bcm_sk(sk);
+	int ifindex = bo->ifindex; /* default ifindex for this bcm_op */
+	struct bcm_msg_head msg_head;
+	int ret; /* read bytes or error codes as return value */
+
+	if (!bo->bound) {
+		DBG("sock %p not bound\n", sk);
+		return -ENOTCONN;
+	}
+
+	/* check for alternative ifindex for this bcm_op */
+
+	if (!ifindex && msg->msg_name) {
+		/* no bound device as default => check msg_name */
+		struct sockaddr_can *addr =
+			(struct sockaddr_can *)msg->msg_name;
+
+		if (addr->can_family != AF_CAN)
+			return -EINVAL;
+
+		ifindex = addr->can_ifindex; /* ifindex from sendto() */
+
+		if (ifindex) {
+			struct net_device *dev;
+
+			dev = dev_get_by_index(&init_net, ifindex);
+			if (!dev) {
+				DBG("device %d not found\n", ifindex);
+				return -ENODEV;
+			}
+
+			if (dev->type != ARPHRD_CAN) {
+				DBG("device %d no CAN device\n", ifindex);
+				dev_put(dev);
+				return -ENODEV;
+			}
+
+			dev_put(dev);
+		}
+	}
+
+	/* read message head information */
+
+	ret = memcpy_fromiovec((u8 *)&msg_head, msg->msg_iov, MHSIZ);
+	if (ret < 0)
+		return ret;
+
+	DBG("opcode %d for can_id %03X\n", msg_head.opcode, msg_head.can_id);
+
+	lock_sock(sk);
+
+	switch (msg_head.opcode) {
+
+	case TX_SETUP:
+		ret = bcm_tx_setup(&msg_head, msg, ifindex, sk);
+		break;
+
+	case RX_SETUP:
+		ret = bcm_rx_setup(&msg_head, msg, ifindex, sk);
+		break;
+
+	case TX_DELETE:
+		if (bcm_delete_tx_op(&bo->tx_ops, msg_head.can_id, ifindex))
+			ret = MHSIZ;
+		else
+			ret = -EINVAL;
+		break;
+
+	case RX_DELETE:
+		if (bcm_delete_rx_op(&bo->rx_ops, msg_head.can_id, ifindex))
+			ret = MHSIZ;
+		else
+			ret = -EINVAL;
+		break;
+
+	case TX_READ:
+		/* reuse msg_head for the reply to TX_READ */
+		msg_head.opcode  = TX_STATUS;
+		ret = bcm_read_op(&bo->tx_ops, &msg_head, ifindex);
+		break;
+
+	case RX_READ:
+		/* reuse msg_head for the reply to RX_READ */
+		msg_head.opcode  = RX_STATUS;
+		ret = bcm_read_op(&bo->rx_ops, &msg_head, ifindex);
+		break;
+
+	case TX_SEND:
+		/* we need at least one can_frame */
+		if (msg_head.nframes < 1)
+			ret = -EINVAL;
+		else
+			ret = bcm_tx_send(msg, ifindex, sk);
+		break;
+
+	default:
+		DBG("Unknown opcode %d\n", msg_head.opcode);
+		ret = -EINVAL;
+		break;
+	}
+
+	release_sock(sk);
+
+	return ret;
+}
+
+/*
+ * notification handler for netdevice status changes
+ */
+static int bcm_notifier(struct notifier_block *nb, unsigned long msg,
+			void *data)
+{
+	struct net_device *dev = (struct net_device *)data;
+	struct bcm_sock *bo = container_of(nb, struct bcm_sock, notifier);
+	struct sock *sk = &bo->sk;
+	struct bcm_op *op;
+	int notify_enodev = 0;
+
+	DBG("msg %ld for dev %p (%s idx %d) sk %p bo->ifindex %d\n",
+	    msg, dev, dev->name, dev->ifindex, sk, bo->ifindex);
+
+	if (dev->nd_net != &init_net)
+		return NOTIFY_DONE;
+
+	if (dev->type != ARPHRD_CAN)
+		return NOTIFY_DONE;
+
+	switch (msg) {
+
+	case NETDEV_UNREGISTER:
+		lock_sock(sk);
+
+		/* remove device specific receive entries */
+		list_for_each_entry(op, &bo->rx_ops, list)
+			if (op->rx_reg_dev == dev)
+				bcm_rx_unreg(dev, op);
+
+		/* remove device reference, if this is our bound device */
+		if (bo->bound && bo->ifindex == dev->ifindex) {
+			bo->bound   = 0;
+			bo->ifindex = 0;
+			notify_enodev = 1;
+		}
+
+		release_sock(sk);
+
+		if (notify_enodev) {
+			sk->sk_err = ENODEV;
+			if (!sock_flag(sk, SOCK_DEAD))
+				sk->sk_error_report(sk);
+		}
+		break;
+
+	case NETDEV_DOWN:
+		if (bo->bound && bo->ifindex == dev->ifindex) {
+			sk->sk_err = ENETDOWN;
+			if (!sock_flag(sk, SOCK_DEAD))
+				sk->sk_error_report(sk);
+		}
+	}
+
+	return NOTIFY_DONE;
+}
+
+/*
+ * initial settings for all BCM sockets to be set at socket creation time
+ */
+static int bcm_init(struct sock *sk)
+{
+	struct bcm_sock *bo = bcm_sk(sk);
+
+	bo->bound            = 0;
+	bo->ifindex          = 0;
+	bo->dropped_usr_msgs = 0;
+	bo->bcm_proc_read    = NULL;
+
+	INIT_LIST_HEAD(&bo->tx_ops);
+	INIT_LIST_HEAD(&bo->rx_ops);
+
+	/* set notifier */
+	bo->notifier.notifier_call = bcm_notifier;
+
+	register_netdevice_notifier(&bo->notifier);
+
+	return 0;
+}
+
+/*
+ * standard socket functions
+ */
+static int bcm_release(struct socket *sock)
+{
+	struct sock *sk = sock->sk;
+	struct bcm_sock *bo = bcm_sk(sk);
+	struct bcm_op *op, *next;
+
+	DBG("socket %p, sk %p\n", sock, sk);
+
+	/* remove bcm_ops, timer, rx_unregister(), etc. */
+
+	unregister_netdevice_notifier(&bo->notifier);
+
+	lock_sock(sk);
+
+	list_for_each_entry_safe(op, next, &bo->tx_ops, list) {
+		DBG("removing tx_op %p for can_id %03X\n", op, op->can_id);
+		bcm_remove_op(op);
+	}
+
+	list_for_each_entry_safe(op, next, &bo->rx_ops, list) {
+		DBG("removing rx_op %p for can_id %03X\n", op, op->can_id);
+
+		/*
+		 * Don't care if we're bound or not (due to netdev problems)
+		 * can_rx_unregister() is always a save thing to do here.
+		 */
+		if (op->ifindex) {
+			/*
+			 * Only remove subscriptions that had not
+			 * been removed due to NETDEV_UNREGISTER
+			 * in bcm_notifier()
+			 */
+			if (op->rx_reg_dev) {
+				struct net_device *dev;
+
+				dev = dev_get_by_index(&init_net, op->ifindex);
+				if (dev) {
+					bcm_rx_unreg(dev, op);
+					dev_put(dev);
+				}
+			}
+		} else
+			can_rx_unregister(NULL, op->can_id,
+					  REGMASK(op->can_id),
+					  bcm_rx_handler, op);
+
+		bcm_remove_op(op);
+	}
+
+	/* remove procfs entry */
+	if (proc_dir && bo->bcm_proc_read)
+		remove_proc_entry(bo->procname, proc_dir);
+
+	/* remove device reference */
+	if (bo->bound) {
+		bo->bound   = 0;
+		bo->ifindex = 0;
+	}
+
+	release_sock(sk);
+	sock_put(sk);
+
+	return 0;
+}
+
+static int bcm_connect(struct socket *sock, struct sockaddr *uaddr, int len,
+		       int flags)
+{
+	struct sockaddr_can *addr = (struct sockaddr_can *)uaddr;
+	struct sock *sk = sock->sk;
+	struct bcm_sock *bo = bcm_sk(sk);
+
+	if (bo->bound)
+		return -EISCONN;
+
+	/* bind a device to this socket */
+	if (addr->can_ifindex) {
+		struct net_device *dev;
+
+		dev = dev_get_by_index(&init_net, addr->can_ifindex);
+		if (!dev) {
+			DBG("could not find device index %d\n",
+			    addr->can_ifindex);
+			return -ENODEV;
+		}
+
+		if (dev->type != ARPHRD_CAN) {
+			DBG("device %d no CAN device\n", addr->can_ifindex);
+			dev_put(dev);
+			return -ENODEV;
+		}
+
+		bo->ifindex = dev->ifindex;
+		dev_put(dev);
+
+		DBG("socket %p bound to device %s (idx %d)\n",
+		    sock, dev->name, dev->ifindex);
+
+	} else {
+		/* no interface reference for ifindex = 0 ('any' CAN device) */
+		bo->ifindex = 0;
+	}
+
+	bo->bound = 1;
+
+	if (proc_dir) {
+		/* unique socket address as filename */
+		sprintf(bo->procname, "%p", sock);
+		bo->bcm_proc_read = create_proc_read_entry(bo->procname, 0644,
+							   proc_dir,
+							   bcm_read_proc, sk);
+	}
+
+	return 0;
+}
+
+static int bcm_recvmsg(struct kiocb *iocb, struct socket *sock,
+		       struct msghdr *msg, size_t size, int flags)
+{
+	struct sock *sk = sock->sk;
+	struct sk_buff *skb;
+	int error = 0;
+	int noblock;
+	int err;
+
+	DBG("socket %p, sk %p\n", sock, sk);
+
+	noblock =  flags & MSG_DONTWAIT;
+	flags   &= ~MSG_DONTWAIT;
+	skb = skb_recv_datagram(sk, flags, noblock, &error);
+	if (!skb)
+		return error;
+
+	DBG("delivering skbuff %p\n", skb);
+	DBG_SKB(skb);
+
+	if (skb->len < size)
+		size = skb->len;
+
+	err = memcpy_toiovec(msg->msg_iov, skb->data, size);
+	if (err < 0) {
+		skb_free_datagram(sk, skb);
+		return err;
+	}
+
+	sock_recv_timestamp(msg, sk, skb);
+
+	if (msg->msg_name) {
+		msg->msg_namelen = sizeof(struct sockaddr_can);
+		memcpy(msg->msg_name, skb->cb, msg->msg_namelen);
+	}
+
+	DBG("freeing sock %p, skbuff %p\n", sk, skb);
+	skb_free_datagram(sk, skb);
+
+	return size;
+}
+
+static unsigned int bcm_poll(struct file *file, struct socket *sock,
+			     poll_table *wait)
+{
+	unsigned int mask = 0;
+
+	DBG("socket %p\n", sock);
+
+	mask = datagram_poll(file, sock, wait);
+	return mask;
+}
+
+static struct proto_ops bcm_ops __read_mostly = {
+	.family        = PF_CAN,
+	.release       = bcm_release,
+	.bind          = sock_no_bind,
+	.connect       = bcm_connect,
+	.socketpair    = sock_no_socketpair,
+	.accept        = sock_no_accept,
+	.getname       = sock_no_getname,
+	.poll          = bcm_poll,
+	.ioctl         = NULL,		/* use can_ioctl() from af_can.c */
+	.listen        = sock_no_listen,
+	.shutdown      = sock_no_shutdown,
+	.setsockopt    = sock_no_setsockopt,
+	.getsockopt    = sock_no_getsockopt,
+	.sendmsg       = bcm_sendmsg,
+	.recvmsg       = bcm_recvmsg,
+	.mmap          = sock_no_mmap,
+	.sendpage      = sock_no_sendpage,
+};
+
+static struct proto bcm_proto __read_mostly = {
+	.name       = "CAN_BCM",
+	.owner      = THIS_MODULE,
+	.obj_size   = sizeof(struct bcm_sock),
+	.init       = bcm_init,
+};
+
+static struct can_proto bcm_can_proto __read_mostly = {
+	.type       = SOCK_DGRAM,
+	.protocol   = CAN_BCM,
+	.capability = -1,
+	.ops        = &bcm_ops,
+	.prot       = &bcm_proto,
+};
+
+static int __init bcm_module_init(void)
+{
+	int err;
+
+	printk(banner);
+
+	err = can_proto_register(&bcm_can_proto);
+	if (err < 0) {
+		printk(KERN_ERR "can: registration of bcm protocol failed\n");
+		return err;
+	}
+
+	/* create /proc/net/can-bcm directory */
+	proc_dir = proc_mkdir("can-"IDENT, init_net.proc_net);
+
+	if (proc_dir)
+		proc_dir->owner = THIS_MODULE;
+
+	return 0;
+}
+
+static void __exit bcm_module_exit(void)
+{
+	can_proto_unregister(&bcm_can_proto);
+
+	if (proc_dir)
+		proc_net_remove(&init_net, "can-"IDENT);
+}
+
+module_init(bcm_module_init);
+module_exit(bcm_module_exit);

--

Re: [PATCH 4/7] CAN: Add broadcast manager (bcm) protocol

[Arnaldo Carvalho de Melo]

Em Tue, Sep 25, 2007 at 02:20:33PM +0200, Urs Thuermann escreveu:
> This patch adds the CAN broadcast manager (bcm) protocol.
> 
> +static void bcm_can_tx(struct bcm_op *op)
> +{
> +	skb = alloc_skb(CFSIZ,
> +			in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);

We have gfp_any() for this:

[acme@filo net-2.6.24]$ grep gfp_any net/*/*.[ch]
net/ipv4/tcp.c:         tcp_send_active_reset(sk, gfp_any());
net/ipv6/route.c:       skb = nlmsg_new(rt6_nlmsg_size(), gfp_any());
net/ipv6/route.c:       err = rtnl_notify(skb, pid, RTNLGRP_IPV6_ROUTE,
nlh, gfp_any());
net/netfilter/nfnetlink.c:      netlink_broadcast(nfnl, skb, pid, group,
gfp_any());
net/netlink/af_netlink.c:       skb = netlink_trim(skb, gfp_any());

[acme@filo net-2.6.24]$ grep in_interrupt net/*/*.[ch]
net/decnet/dn_route.c:  int user_mode = !in_interrupt();
net/decnet/dn_table.c:  if (in_interrupt() && net_ratelimit()) {
[acme@filo net-2.6.24]$

> +static void bcm_send_to_user(struct bcm_op *op, struct bcm_msg_head *head,
> +			     struct can_frame *frames, int has_timestamp)
> +{
> +	struct sk_buff *skb;
> +	struct can_frame *firstframe;
> +	struct sockaddr_can *addr;
> +	struct sock *sk = op->sk;
> +	int datalen = head->nframes * CFSIZ;
> +	int err;
> +
> +	skb = alloc_skb(sizeof(*head) + datalen,
> +			in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);

ditto

Re: [PATCH 4/7] CAN: Add broadcast manager (bcm) protocol

[Urs Thuermann]

Arnaldo Carvalho de Melo <acme@ghostprotocols.net> writes:

> > +	skb = alloc_skb(CFSIZ,
> > +			in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
> 
> We have gfp_any() for this:

Ah, ok.  That looks better.  Applied.

urs

[PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

[-- Attachment #1: 05-can-vcan-driver.diff --]
[-- Type: text/plain, Size: 9148 bytes --]

This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 drivers/net/Makefile     |    1 
 drivers/net/can/Kconfig  |   25 +++++
 drivers/net/can/Makefile |    5 +
 drivers/net/can/vcan.c   |  208 +++++++++++++++++++++++++++++++++++++++++++++++
 net/can/Kconfig          |    3 
 5 files changed, 242 insertions(+)

Index: net-2.6.24/drivers/net/Makefile
===================================================================
--- net-2.6.24.orig/drivers/net/Makefile	2007-09-25 13:28:42.000000000 +0200
+++ net-2.6.24/drivers/net/Makefile	2007-09-25 13:32:23.000000000 +0200
@@ -10,6 +10,7 @@
 obj-$(CONFIG_CHELSIO_T1) += chelsio/
 obj-$(CONFIG_CHELSIO_T3) += cxgb3/
 obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
 obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_ATL1) += atl1/
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: net-2.6.24/drivers/net/can/Kconfig
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/drivers/net/can/Kconfig	2007-09-25 13:32:23.000000000 +0200
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+	depends on CAN
+
+config CAN_VCAN
+	tristate "Virtual Local CAN Interface (vcan)"
+ 	depends on CAN
+	default N
+ 	---help---
+	  Similar to the network loopback devices, vcan offers a
+	  virtual local CAN interface.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called vcan.
+
+config CAN_DEBUG_DEVICES
+	bool "CAN devices debugging messages"
+	depends on CAN
+	default N
+	---help---
+	  Say Y here if you want the CAN device drivers to produce a bunch of
+	  debug messages to the system log.  Select this if you are having
+	  a problem with CAN support and want to see more of what is going
+	  on.
+
+endmenu
Index: net-2.6.24/drivers/net/can/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/drivers/net/can/Makefile	2007-09-25 13:32:23.000000000 +0200
@@ -0,0 +1,5 @@
+#
+#  Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN)		+= vcan.o
Index: net-2.6.24/drivers/net/can/vcan.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/drivers/net/can/vcan.c	2007-09-25 13:32:23.000000000 +0200
@@ -0,0 +1,208 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions, the following disclaimer and
+ *    the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/if_arp.h>
+#include <linux/if_ether.h>
+#include <linux/can.h>
+#include <net/rtnetlink.h>
+
+static __initdata const char banner[] =
+	KERN_INFO "vcan: Virtual CAN interface driver\n";
+
+MODULE_DESCRIPTION("virtual CAN interface");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
+
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+static int debug;
+module_param(debug, int, S_IRUGO);
+#endif
+
+/* To be moved to linux/can/dev.h */
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+#define DBG(fmt, args...)  (debug & 1 ? \
+				printk(KERN_DEBUG "vcan %s: " fmt, \
+				__func__, ##args) : 0)
+#else
+#define DBG(fmt, args...)
+#endif
+
+
+/*
+ * CAN test feature:
+ * Enable the loopback on driver level for testing the CAN core loopback modes.
+ * See Documentation/networking/can.txt for details.
+ */
+
+static int loopback; /* loopback testing. Default: 0 (Off) */
+module_param(loopback, int, S_IRUGO);
+MODULE_PARM_DESC(loopback, "Loop back frames (for testing). Default: 0 (Off)");
+
+
+static int vcan_open(struct net_device *dev)
+{
+	DBG("%s: interface up\n", dev->name);
+
+	netif_start_queue(dev);
+	return 0;
+}
+
+static int vcan_stop(struct net_device *dev)
+{
+	DBG("%s: interface down\n", dev->name);
+
+	netif_stop_queue(dev);
+	return 0;
+}
+
+static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+
+	stats->rx_packets++;
+	stats->rx_bytes += skb->len;
+
+	skb->protocol  = htons(ETH_P_CAN);
+	skb->pkt_type  = PACKET_BROADCAST;
+	skb->dev       = dev;
+	skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	DBG("received skbuff on interface %d\n", dev->ifindex);
+
+	netif_rx(skb);
+}
+
+static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+	int loop;
+
+	DBG("sending skbuff on interface %s\n", dev->name);
+
+	stats->tx_packets++;
+	stats->tx_bytes += skb->len;
+
+	/* set flag whether this packet has to be looped back */
+	loop = skb->pkt_type == PACKET_LOOPBACK;
+
+	if (!loopback) {
+		/* no loopback handling available inside this driver */
+
+		if (loop) {
+			/*
+			 * only count the packets here, because the
+			 * CAN core already did the loopback for us
+			 */
+			stats->rx_packets++;
+			stats->rx_bytes += skb->len;
+		}
+		kfree_skb(skb);
+		return 0;
+	}
+
+	/* perform standard loopback handling for CAN network interfaces */
+
+	if (loop) {
+		struct sock *srcsk = skb->sk;
+
+		skb = skb_share_check(skb, GFP_ATOMIC);
+		if (!skb)
+			return 0;
+
+		/* receive with packet counting */
+		skb->sk = srcsk;
+		vcan_rx(skb, dev);
+	} else {
+		/* no looped packets => no counting */
+		kfree_skb(skb);
+	}
+	return 0;
+}
+
+static void vcan_setup(struct net_device *dev)
+{
+	DBG("dev %s\n", dev->name);
+
+	dev->type              = ARPHRD_CAN;
+	dev->mtu               = sizeof(struct can_frame);
+	dev->hard_header_len   = 0;
+	dev->addr_len          = 0;
+	dev->tx_queue_len      = 0;
+	dev->flags             = IFF_NOARP;
+
+	/* set flags according to driver capabilities */
+	if (loopback)
+		dev->flags |= IFF_LOOPBACK;
+
+	dev->open              = vcan_open;
+	dev->stop              = vcan_stop;
+	dev->hard_start_xmit   = vcan_tx;
+	dev->destructor        = free_netdev;
+}
+
+static struct rtnl_link_ops vcan_link_ops __read_mostly = {
+       .kind           = "vcan",
+       .setup          = vcan_setup,
+};
+
+static __init int vcan_init_module(void)
+{
+	printk(banner);
+
+	if (loopback)
+		printk(KERN_INFO "vcan: enabled loopback on driver level.\n");
+
+	return rtnl_link_register(&vcan_link_ops);
+}
+
+static __exit void vcan_cleanup_module(void)
+{
+	rtnl_link_unregister(&vcan_link_ops);
+}
+
+module_init(vcan_init_module);
+module_exit(vcan_cleanup_module);
Index: net-2.6.24/net/can/Kconfig
===================================================================
--- net-2.6.24.orig/net/can/Kconfig	2007-09-25 13:32:23.000000000 +0200
+++ net-2.6.24/net/can/Kconfig	2007-09-25 13:32:23.000000000 +0200
@@ -47,3 +47,6 @@
 	  Say Y here if you want the CAN core to produce a bunch of debug
 	  messages to the system log.  Select this if you are having a
 	  problem with CAN support and want to see more of what is going on.
+
+
+source "drivers/net/can/Kconfig"

--

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[YOSHIFUJI Hideaki / 吉藤英明]

Hello.

In article <20070925122244.15989.5@janus.isnogud.escape.de> (at Tue, 25 Sep 2007 14:20:34 +0200), Urs Thuermann <urs@isnogud.escape.de> says:

> Index: net-2.6.24/drivers/net/can/vcan.c
> ===================================================================
> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ net-2.6.24/drivers/net/can/vcan.c	2007-09-25 13:32:23.000000000 +0200
> @@ -0,0 +1,208 @@
> +/*
> + * vcan.c - Virtual CAN interface
> + *
> + * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *    notice, this list of conditions, the following disclaimer and
> + *    the referenced file 'COPYING'.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *    notice, this list of conditions and the following disclaimer in the
> + *    documentation and/or other materials provided with the distribution.
> + * 3. Neither the name of Volkswagen nor the names of its contributors
> + *    may be used to endorse or promote products derived from this software
> + *    without specific prior written permission.
> + *
> + * Alternatively, provided that this notice is retained in full, this
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + * software may be distributed under the terms of the GNU General
> + * Public License ("GPL") version 2 as distributed in the 'COPYING'
> + * file from the main directory of the linux kernel source.
> + *
> + * The provided data structures and external interfaces from this code
> + * are not restricted to be used by modules with a GPL compatible license.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> + * DAMAGE.
> + *
> + * Send feedback to <socketcan-users@lists.berlios.de>
> + *
> + */

I'm not a lawyer, but the following lines:

| + * Alternatively, provided that this notice is retained in full, this
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| + * software may be distributed under the terms of the GNU General
| + * Public License ("GPL") version 2 as distributed in the 'COPYING'
| + * file from the main directory of the linux kernel source.

make this whole licence imcompatible with GPL.
I do think you need to allow people to select GPLv2 only.

--yoshfuji

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

YOSHIFUJI Hideaki / È£ÑÀ  <yoshfuji@linux-ipv6.org> writes:

> I'm not a lawyer, but the following lines:
> 
> | + * Alternatively, provided that this notice is retained in full, this
>                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | + * software may be distributed under the terms of the GNU General
> | + * Public License ("GPL") version 2 as distributed in the 'COPYING'
> | + * file from the main directory of the linux kernel source.
> 
> make this whole licence imcompatible with GPL.

I'm no lawyer at all, either.  And also Oliver is not, but he has
carried out the fights with our company lawyers.  Maybe he can say
something about whether we can change this.

> I do think you need to allow people to select GPLv2 only.

The sentence you cite *does* allow distribution under GPLv2 only.  And
I think I have often read the restriction to retain such licences in
full in GPLv2 code.  Is that really incompatible?

urs

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Urs Thuermann wrote:
> YOSHIFUJI Hideaki / È£ÑÀ  <yoshfuji@linux-ipv6.org> writes:
> 
> 
>>I'm not a lawyer, but the following lines:
>>
>>| + * Alternatively, provided that this notice is retained in full, this
>>                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>| + * software may be distributed under the terms of the GNU General
>>| + * Public License ("GPL") version 2 as distributed in the 'COPYING'
>>| + * file from the main directory of the linux kernel source.
>>
>>make this whole licence imcompatible with GPL.
> 
> 
> I'm no lawyer at all, either.  And also Oliver is not, but he has
> carried out the fights with our company lawyers.  Maybe he can say
> something about whether we can change this.
> 
> 
>>I do think you need to allow people to select GPLv2 only.
> 
> 
> The sentence you cite *does* allow distribution under GPLv2 only.  And
> I think I have often read the restriction to retain such licences in
> full in GPLv2 code.  Is that really incompatible?


Not that it necessarily means its valid, but there are multiple
files in the kernel that carry the exact same term:

arch/x86_64/crypto/aes.c
arch/i386/crypto/aes.c
crypto/gf128mul.c
crypto/aes.c
drivers/net/ppp_mppe.c
drivers/crypto/padlock-aes.c
include/crypto/b128ops.h
include/crypto/gf128mul.h

OTOH I tend to agree with Yoshifuji that once someone has
selected the GPL and has made enough changes that no parts
"can be reasonably considered independent and separate works",
it seems like an additional and confusing restriction to be
forced to retain ineffective licensing terms.

But since I'm not a lawyer either I'm going to refrain from
further speculation :)

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Patrick McHardy wrote:
> Urs Thuermann wrote:
>   
>> YOSHIFUJI Hideaki / È£ÑÀ  <yoshfuji@linux-ipv6.org> writes:
>>
>>
>>     
>>> I'm not a lawyer, but the following lines:
>>>
>>> | + * Alternatively, provided that this notice is retained in full, this
>>>                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> | + * software may be distributed under the terms of the GNU General
>>> | + * Public License ("GPL") version 2 as distributed in the 'COPYING'
>>> | + * file from the main directory of the linux kernel source.
>>>
>>> make this whole licence imcompatible with GPL.
>>>       
>>     

The module license is "Dual BSD/GPL" as many other code in the Linux
Kernel. So this should not be any problem.


>>> I do think you need to allow people to select GPLv2 only.
>>>       
>>     

The Linux Kernel is currently under GPLv2 and we just wanted to follow
Linus' mind and so we referenced the COPYING file which many other
source does as well. Indeed it was a hard thing to make our code
available under GPL (as creating and publishing open source software is
really no a usual thing for the Volkswagen rights department). So i
discussed with the rights department about several disclaimers inside
the current Kernel (especially the stuff that has been signed off by
companies like IBM, Motorola, etc.). In this process it turned out to be
the best to license the code under "Dual BSD/GPL" as it grants more
rights to the programmer (including ourselves) than a GPL only license.
I assume this was the intention from IBM, Motorola and all the others
also. Btw. inside the Kernel context it behaves exactly like GPL code
(like all the other dual license code).

So i really can't see any problem here. If so there would have been a
big discussion about the other "Dual BSD/GPL" code.

Best regards,
Oliver

ps. I hope, i found the right words right now, as i'm not very familiar
with English :)

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Oliver Hartkopp wrote:
>>>>I do think you need to allow people to select GPLv2 only.
>>>>      
>>>
> The Linux Kernel is currently under GPLv2 and we just wanted to follow
> Linus' mind and so we referenced the COPYING file which many other
> source does as well. Indeed it was a hard thing to make our code
> available under GPL (as creating and publishing open source software is
> really no a usual thing for the Volkswagen rights department). So i
> discussed with the rights department about several disclaimers inside
> the current Kernel (especially the stuff that has been signed off by
> companies like IBM, Motorola, etc.). In this process it turned out to be
> the best to license the code under "Dual BSD/GPL" as it grants more
> rights to the programmer (including ourselves) than a GPL only license.
> I assume this was the intention from IBM, Motorola and all the others
> also. Btw. inside the Kernel context it behaves exactly like GPL code
> (like all the other dual license code).
> 
> So i really can't see any problem here. If so there would have been a
> big discussion about the other "Dual BSD/GPL" code.


Yoshifuji's point was that the license seems to contradict itself,
it says you may choose GPL, but have to retain BSD. And that is
not about Dual BSD/GPL but about the specific wording.

/me runs and refrains from the discussion as promised :)

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Patrick McHardy wrote:
>
> Yoshifuji's point was that the license seems to contradict itself,
> it says you may choose GPL, but have to retain BSD. And that is
> not about Dual BSD/GPL but about the specific wording.
>   

Got it (finally)!

Trying to specify the GPL Version (and the reference to the COPYING
file) i just overlooked  the second part
 "*/*/in which case the provisions of the GPL apply INSTEAD OF those
given above."/*/* of the original sentence.

Sorry. Was no* malice aforethought :)*

Of course we'll fix this to have the same wording like e.g. in
arch/i386/crypto/aes.c .

Thanks to Yoshfuji for catching this and to Patrick for making it clear
to me!*

Best regards,
Oliver

*

[PATCH 6/7] CAN: Add maintainer entries

[Urs Thuermann]

[-- Attachment #1: 06-can-maintainers.diff --]
[-- Type: text/plain, Size: 1734 bytes --]

This patch adds entries in the CREDITS and MAINTAINERS file for CAN.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 CREDITS     |   16 ++++++++++++++++
 MAINTAINERS |    9 +++++++++
 2 files changed, 25 insertions(+)

Index: net-2.6.24/CREDITS
===================================================================
--- net-2.6.24.orig/CREDITS	2007-09-20 18:48:21.000000000 +0200
+++ net-2.6.24/CREDITS	2007-09-20 18:49:00.000000000 +0200
@@ -1331,6 +1331,14 @@
 S: 5623 HZ Eindhoven
 S: The Netherlands
 
+N: Oliver Hartkopp
+E: oliver.hartkopp@volkswagen.de
+W: http://www.volkswagen.de
+D: Controller Area Network (network layer core)
+S: Brieffach 1776
+S: 38436 Wolfsburg
+S: Germany
+
 N: Andrew Haylett
 E: ajh@primag.co.uk
 D: Selection mechanism
@@ -3284,6 +3292,14 @@
 S: F-35042 Rennes Cedex
 S: France
 
+N: Urs Thuermann
+E: urs.thuermann@volkswagen.de
+W: http://www.volkswagen.de
+D: Controller Area Network (network layer core)
+S: Brieffach 1776
+S: 38436 Wolfsburg
+S: Germany
+
 N: Jon Tombs
 E: jon@gte.esi.us.es
 W: http://www.esi.us.es/~jon
Index: net-2.6.24/MAINTAINERS
===================================================================
--- net-2.6.24.orig/MAINTAINERS	2007-09-20 18:48:21.000000000 +0200
+++ net-2.6.24/MAINTAINERS	2007-09-20 18:49:00.000000000 +0200
@@ -975,6 +975,15 @@
 L:	video4linux-list@redhat.com
 S:	Maintained
 
+CAN NETWORK LAYER
+P:	Urs Thuermann
+M:	urs.thuermann@volkswagen.de
+P:	Oliver Hartkopp
+M:	oliver.hartkopp@volkswagen.de
+L:	socketcan-core@lists.berlios.de
+W:	http://developer.berlios.de/projects/socketcan/
+S:	Maintained
+
 CALGARY x86-64 IOMMU
 P:	Muli Ben-Yehuda
 M:	muli@il.ibm.com

--

[PATCH 7/7] CAN: Add documentation

[Urs Thuermann]

[-- Attachment #1: 07-can-doc.diff --]
[-- Type: text/plain, Size: 29326 bytes --]

This patch adds documentation for the PF_CAN protocol family.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 Documentation/networking/00-INDEX |    2 
 Documentation/networking/can.txt  |  634 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 636 insertions(+)

Index: net-2.6.24/Documentation/networking/can.txt
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/Documentation/networking/can.txt	2007-09-25 13:28:26.000000000 +0200
@@ -0,0 +1,634 @@
+============================================================================
+
+can.txt
+
+Readme file for the Controller Area Network Protocol Family (aka Socket CAN)
+
+This file contains
+
+  1 Overview / What is Socket CAN
+
+  2 Motivation / Why using the socket API
+
+  3 Socket CAN concept
+    3.1 receive lists
+    3.2 loopback
+    3.3 network security issues (capabilities)
+    3.4 network problem notifications
+
+  4 How to use Socket CAN
+    4.1 RAW protocol sockets with can_filters (SOCK_RAW)
+      4.1.1 RAW socket option CAN_RAW_FILTER
+      4.1.2 RAW socket option CAN_RAW_ERR_FILTER
+      4.1.3 RAW socket option CAN_RAW_LOOPBACK
+      4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
+    4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
+    4.3 connected transport protocols (SOCK_SEQPACKET)
+    4.4 unconnected transport protocols (SOCK_DGRAM)
+
+  5 Socket CAN core module
+    5.1 can.ko module params
+    5.2 procfs content
+    5.3 writing own CAN protocol modules
+
+  6 CAN network drivers
+    6.1 general settings
+    6.2 loopback
+    6.3 CAN controller hardware filters
+    6.4 currently supported CAN hardware
+    6.5 todo
+
+  7 Credits
+
+============================================================================
+
+1. Overview / What is Socket CAN
+--------------------------------
+
+The socketcan package is an implementation of CAN protocols
+(Controller Area Network) for Linux.  CAN is a networking technology
+which has widespread use in automation, embedded devices, and
+automotive fields.  While there have been other CAN implementations
+for Linux based on character devices, Socket CAN uses the Berkeley
+socket API, the Linux network stack and implements the CAN device
+drivers as network interfaces.  The CAN socket API has been designed
+as similar as possible to the TCP/IP protocols to allow programmers,
+familiar with network programming, to easily learn how to use CAN
+sockets.
+
+2. Motivation / Why using the socket API
+----------------------------------------
+
+There have been CAN implementations for Linux before Socket CAN so the
+question arises, why we have started another project.  Most existing
+implementations come as a device driver for some CAN hardware, they
+are based on character devices and provide comparatively little
+functionality.  Usually, there is only a hardware-specific device
+driver which provides a character device interface to send and
+receive raw CAN frames, directly to/from the controller hardware.
+Queueing of frames and higher-level transport protocols like ISO-TP
+have to be implemented in user space applications.  Also, most
+character-device implementations support only one single process to
+open the device at a time, similar to a serial interface.  Exchanging
+the CAN controller requires employment of another device driver and
+often the need for adaption of large parts of the application to the
+new driver's API.
+
+Socket CAN was designed to overcome all of these limitations.  A new
+protocol family has been implemented which provides a socket interface
+to user space applications and which builds upon the Linux network
+layer, so to use all of the provided queueing functionality.  A device
+driver for CAN controller hardware registers itself with the Linux
+network layer as a network device, so that CAN frames from the
+controller can be passed up to the network layer and on to the CAN
+protocol family module and also vice-versa.  Also, the protocol family
+module provides an API for transport protocol modules to register, so
+that any number of transport protocols can be loaded or unloaded
+dynamically.  In fact, the can core module alone does not provide any
+protocol and cannot be used without loading at least one additional
+protocol module.  Multiple sockets can be opened at the same time,
+on different or the same protocol module and they can listen/send
+frames on different or the same CAN IDs.  Several sockets listening on
+the same interface for frames with the same CAN ID are all passed the
+same received matching CAN frames.  An application wishing to
+communicate using a specific transport protocol, e.g. ISO-TP, just
+selects that protocol when opening the socket, and then can read and
+write application data byte streams, without having to deal with
+CAN-IDs, frames, etc.
+
+Similar functionality visible from user-space could be provided by a
+character device, too, but this would lead to a technically inelegant
+solution for a couple of reasons:
+
+* Intricate usage.  Instead of passing a protocol argument to
+  socket(2) and using bind(2) to select a CAN interface and CAN ID, an
+  application would have to do all these operations using ioctl(2)s.
+
+* Code duplication.  A character device cannot make use of the Linux
+  network queueing code, so all that code would have to be duplicated
+  for CAN networking.
+
+* Abstraction.  In most existing character-device implementations, the
+  hardware-specific device driver for a CAN controller directly
+  provides the character device for the application to work with.
+  This is at least very unusual in Unix systems for both, char and
+  block devices.  For example you don't have a character device for a
+  certain UART of a serial interface, a certain sound chip in your
+  computer, a SCSI or IDE controller providing access to your hard
+  disk or tape streamer device.  Instead, you have abstraction layers
+  which provide a unified character or block device interface to the
+  application on the one hand, and a interface for hardware-specific
+  device drivers on the other hand.  These abstractions are provided
+  by subsystems like the tty layer, the audio subsystem or the SCSI
+  and IDE subsystems for the devices mentioned above.
+
+  The easiest way to implement a CAN device driver is as a character
+  device without such a (complete) abstraction layer, as is done by most
+  existing drivers.  The right way, however, would be to add such a
+  layer with all the functionality like registering for certain CAN
+  IDs, supporting several open file descriptors and (de)multiplexing
+  CAN frames between them, (sophisticated) queueing of CAN frames, and
+  providing an API for device drivers to register with.  However, then
+  it would be no more difficult, or may be even easier, to use the
+  networking framework provided by the Linux kernel, and this is what
+  Socket CAN does.
+
+  The use of the networking framework of the Linux kernel is just the
+  natural and most appropriate way to implement CAN for Linux.
+
+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 network layer. In contrast to the commonly known
+  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.1 receive lists
+
+  The network transparent access of multiple applications leads to the
+  problem that different applications may be interested in the same
+  CAN-IDs from the same CAN network interface. The Socket CAN core
+  module - which implements the protocol family CAN - provides several
+  high efficient receive lists for this reason. If e.g. a user space
+  application opens a CAN RAW socket, the raw protocol module itself
+  requests the (range of) CAN-IDs from the Socket CAN core that are
+  requested by the user. The subscription and unsubscription of
+  CAN-IDs can be done for specific CAN interfaces or for all(!) known
+  CAN interfaces with the can_rx_(un)register() functions provided to
+  CAN protocol modules by the SocketCAN core (see chapter 5).
+  To optimize the CPU usage at runtime the receive lists are split up
+  into several specific lists per device that match the requested
+  filter complexity for a given use-case.
+
+  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 reception of a high prio CAN frame. To
+  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.
+
+  3.3 network security issues (capabilities)
+
+  The Controller Area Network is a local field bus transmitting only
+  broadcast messages without any routing and security concepts.
+  In the majority of cases the user application has to deal with
+  raw CAN frames. Therefore it might be reasonable NOT to restrict
+  the CAN access only to the user root, as known from other networks.
+  Since the currently implemented CAN_RAW and CAN_BCM sockets can only
+  send and receive frames to/from CAN interfaces it does not affect
+  security of others networks to allow all users to access the CAN.
+  To enable non-root users to access CAN_RAW and CAN_BCM protocol
+  sockets the Kconfig options CAN_RAW_USER and/or CAN_BCM_USER may be
+  selected at kernel compile time.
+
+  3.4 network problem notifications
+
+  The use of the CAN bus may lead to several problems on the physical
+  and media access control layer. Detecting and logging of these lower
+  layer problems is a vital requirement for CAN users to identify
+  hardware issues on the physical transceiver layer as well as
+  arbitration problems and error frames caused by the different
+  ECUs. The occurrence of detected errors are important for diagnosis
+  and have to be logged together with the exact timestamp. For this
+  reason the CAN interface driver can generate so called Error Frames
+  that can optionally be passed to the user application in the same
+  way as other CAN frames. Whenever an error on the physical layer
+  or the MAC layer is detected (e.g. by the CAN controller) the driver
+  creates an appropriate error frame. Error frames can be requested by
+  the user application using the common CAN filter mechanisms. Inside
+  this filter definition the (interested) type of errors may be
+  selected. The reception of error frames is disabled by default.
+
+4. How to use Socket CAN
+------------------------
+
+  Like TCP/IP, you first need to open a socket for communicating over a
+  CAN network. Since Socket CAN implements a new protocol family, you
+  need to pass PF_CAN as the first argument to the socket(2) system
+  call. Currently, there are two CAN protocols to choose from, the raw
+  socket protocol and the broadcast manager (BCM). So to open a socket,
+  you would write
+
+    s = socket(PF_CAN, SOCK_RAW, CAN_RAW);
+
+  and
+
+    s = socket(PF_CAN, SOCK_DGRAM, CAN_BCM);
+
+  respectively.  After the successful creation of the socket, you would
+  normally use the bind(2) system call to bind the socket to a CAN
+  interface (which is different from TCP/IP due to different addressing
+  - see chapter 3). After binding (CAN_RAW) or connecting (CAN_BCM)
+  the socket, you can read(2) and write(2) from/to the socket or use
+  send(2), sendto(2), sendmsg(2) and the recv* counterpart operations
+  on the socket as usual. There are also CAN specific socket options
+  described below.
+
+  The basic CAN frame structure and the sockaddr structure are defined
+  in include/linux/can.h:
+
+    struct can_frame {
+            canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
+            __u8    can_dlc; /* data length code: 0 .. 8 */
+            __u8    data[8] __attribute__((aligned(8)));
+    };
+
+  The alignment of the (linear) payload data[] to a 64bit boundary
+  allows the user to define own structs and unions to easily access the
+  CAN payload. There is no given byteorder on the CAN bus by
+  default. A read(2) system call on a CAN_RAW socket transfers a
+  struct can_frame to the user space.
+
+  The sockaddr_can structure has an interface index like the
+  PF_PACKET socket, that also binds to a specific interface:
+
+    struct sockaddr_can {
+            sa_family_t can_family;
+            int         can_ifindex;
+            union {
+                    struct { canid_t rx_id, tx_id; } tp16;
+                    struct { canid_t rx_id, tx_id; } tp20;
+                    struct { canid_t rx_id, tx_id; } mcnet;
+                    struct { canid_t rx_id, tx_id; } isotp;
+            } can_addr;
+    };
+
+  To determine the interface index an appropriate ioctl() has to
+  be used (example for CAN_RAW sockets without error checking):
+
+    int s;
+    struct sockaddr_can addr;
+    struct ifreq ifr;
+
+    s = socket(PF_CAN, SOCK_RAW, CAN_RAW);
+
+    strcpy(ifr.ifr_name, "can0" );
+    ioctl(s, SIOCGIFINDEX, &ifr);
+
+    addr.can_family = AF_CAN;
+    addr.can_ifindex = ifr.ifr_ifindex;
+
+    bind(s, (struct sockaddr *)&addr, sizeof(addr));
+
+    (..)
+
+  To bind a socket to all(!) CAN interfaces the interface index must
+  be 0 (zero). In this case the socket receives CAN frames from every
+  enabled CAN interface. To determine the originating CAN interface
+  the system call recvfrom(2) may be used instead of read(2). To send
+  on a socket that is bound to 'any' interface sendto(2) is needed to
+  specify the outgoing interface.
+
+  Reading CAN frames from a bound CAN_RAW socket (see above) consists
+  of reading a struct can_frame:
+
+    struct can_frame frame;
+
+    nbytes = read(s, &frame, sizeof(struct can_frame));
+
+    if (nbytes < 0) {
+            perror("can raw socket read");
+            return 1;
+    }
+
+    /* paraniod check ... */
+    if (nbytes < sizeof(struct can_frame)) {
+            fprintf(stderr, "read: incomplete CAN frame\n");
+            return 1;
+    }
+
+    /* do something with the received CAN frame */
+
+  Writing CAN frames can be done similarly, with the write(2) system call:
+
+    nbytes = write(s, &frame, sizeof(struct can_frame));
+
+  When the CAN interface is bound to 'any' existing CAN interface
+  (addr.can_ifindex = 0) it is recommended to use recvfrom(2) if the
+  information about the originating CAN interface is needed:
+
+    struct sockaddr_can addr;
+    struct ifreq ifr;
+    socklen_t len = sizeof(addr);
+    struct can_frame frame;
+
+    nbytes = recvfrom(s, &frame, sizeof(struct can_frame),
+                      0, (struct sockaddr*)&addr, &len);
+
+    /* get interface name of the received CAN frame */
+    ifr.ifr_ifindex = addr.can_ifindex;
+    ioctl(s, SIOCGIFNAME, &ifr);
+    printf("Received a CAN frame from interface %s", ifr.ifr_name);
+
+  To write CAN frames on sockets bound to 'any' CAN interface the
+  outgoing interface has to be defined certainly.
+
+    strcpy(ifr.ifr_name, "can0");
+    ioctl(s, SIOCGIFINDEX, &ifr);
+    addr.can_ifindex = ifr.ifr_ifindex;
+    addr.can_family  = AF_CAN;
+
+    nbytes = sendto(s, &frame, sizeof(struct can_frame),
+                    0, (struct sockaddr*)&addr, sizeof(addr));
+
+  4.1 RAW protocol sockets with can_filters (SOCK_RAW)
+
+  Using CAN_RAW sockets is extensively comparable to the commonly
+  known access to CAN character devices. To meet the new possibilities
+  provided by the multi user SocketCAN approach, some reasonable
+  defaults are set at RAW socket binding time:
+
+  - The filters are set to exactly one filter receiving everything
+  - The socket only receives valid data frames (=> no error frames)
+  - The loopback of sent CAN frames is enabled (see chapter 3.2)
+  - The socket does not receive its own sent frames (in loopback mode)
+
+  These default settings may be changed before or after binding the socket.
+  To use the referenced definitions of the socket options for CAN_RAW
+  sockets, include <linux/can/raw.h>.
+
+  4.1.1 RAW socket option CAN_RAW_FILTER
+
+  The reception of CAN frames using CAN_RAW sockets can be controlled
+  by defining 0 .. n filters with the CAN_RAW_FILTER socket option.
+
+  The CAN filter structure is defined in include/linux/can.h:
+
+    struct can_filter {
+            canid_t can_id;
+            canid_t can_mask;
+    };
+
+  A filter matches, when
+
+    <received_can_id> & mask == can_id & mask
+
+  which is analogous to known CAN controllers hardware filter semantics.
+  The filter can be inverted in this semantic, when the CAN_INV_FILTER
+  bit is set in can_id element of the can_filter structure. In
+  contrast to CAN controller hardware filters the user may set 0 .. n
+  receive filters for each open socket separately:
+
+    struct can_filter rfilter[2];
+
+    rfilter[0].can_id   = 0x123;
+    rfilter[0].can_mask = CAN_SFF_MASK;
+    rfilter[1].can_id   = 0x200;
+    rfilter[1].can_mask = 0x700;
+
+    setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, &rfilter, sizeof(rfilter));
+
+  To disable the reception of CAN frames on the selected CAN_RAW socket:
+
+    setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, NULL, 0);
+
+  To set the filters to zero filters is quite obsolete as not read
+  data causes the raw socket to discard the received CAN frames. But
+  having this 'send only' use-case we may remove the receive list in the
+  Kernel to save a little (really a very little!) CPU usage.
+
+  4.1.2 RAW socket option CAN_RAW_ERR_FILTER
+
+  As described in chapter 3.4 the CAN interface driver can generate so
+  called Error Frames that can optionally be passed to the user
+  application in the same way as other CAN frames. The possible
+  errors are divided into different error classes that may be filtered
+  using the appropriate error mask. To register for every possible
+  error condition CAN_ERR_MASK can be used as value for the error mask.
+  The values for the error mask are defined in linux/can/error.h .
+
+    can_err_mask_t err_mask = ( CAN_ERR_TX_TIMEOUT | CAN_ERR_BUSOFF );
+
+    setsockopt(s, SOL_CAN_RAW, CAN_RAW_ERR_FILTER,
+               &err_mask, sizeof(err_mask));
+
+  4.1.3 RAW socket option CAN_RAW_LOOPBACK
+
+  To meet multi user needs the local loopback is enabled by default
+  (see chapter 3.2 for details). But in some embedded use-cases
+  (e.g. when only one application uses the CAN bus) this loopback
+  functionality can be disabled (separately for each socket):
+
+    int loopback = 0; /* 0 = disabled, 1 = enabled (default) */
+
+    setsockopt(s, SOL_CAN_RAW, CAN_RAW_LOOPBACK, &loopback, sizeof(loopback));
+
+  4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
+
+  When the local loopback is enabled, all the sent CAN frames are
+  looped back to the open CAN sockets that registered for the CAN
+  frames' CAN-ID on this given interface to meet the multi user
+  needs. The reception of the CAN frames on the same socket that was
+  sending the CAN frame is assumed to be unwanted and therefore
+  disabled by default. This default behaviour may be changed on
+  demand:
+
+    int recv_own_msgs = 1; /* 0 = disabled (default), 1 = enabled */
+
+    setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS,
+               &recv_own_msgs, sizeof(recv_own_msgs));
+
+  4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
+  4.3 connected transport protocols (SOCK_SEQPACKET)
+  4.4 unconnected transport protocols (SOCK_DGRAM)
+
+
+5. Socket CAN core module
+-------------------------
+
+  The Socket CAN core module implements the protocol family
+  PF_CAN. CAN protocol modules are loaded by the core module at
+  runtime. The core module provides an interface for CAN protocol
+  modules to subscribe needed CAN IDs (see chapter 3.1).
+
+  5.1 can.ko module params
+
+  - stats_timer: To calculate the Socket CAN core statistics
+    (e.g. current/maximum frames per second) this 1 second timer is
+    invoked at can.ko module start time by default. This timer can be
+    disabled by using stattimer=0 on the module comandline.
+
+  - debug: When the Kconfig option CONFIG_CAN_DEBUG_CORE is set at
+    compile time, the debug output code is compiled into the module.
+    debug = 0x01 => print general debug information
+    debug = 0x02 => print content of processed CAN frames
+    debug = 0x04 => print content of processed socket buffers
+
+    It is possible to use ORed values e.g. 3 or 7 for an output of
+    all available debug information. Using 0x02 and 0x04 may flood
+    your kernel log - so be careful.
+
+  5.2 procfs content
+
+  As described in chapter 3.1 the Socket CAN core uses several filter
+  lists to deliver received CAN frames to CAN protocol modules. These
+  receive lists, their filters and the count of filter matches can be
+  checked in the appropriate receive list. All entries contain the
+  device and a protocol module identifier:
+
+    foo@bar:~$ cat /proc/net/can/rcvlist_all
+
+    receive list 'rx_all':
+      (vcan3: no entry)
+      (vcan2: no entry)
+      (vcan1: no entry)
+      device   can_id   can_mask  function  userdata   matches  ident
+       vcan0     000    00000000  f88e6370  f6c6f400         0  raw
+      (any: no entry)
+
+  In this example an application requests any CAN traffic from vcan0.
+
+    rcvlist_all - list for unfiltered entries (no filter operations)
+    rcvlist_eff - list for single extended frame (EFF) entries
+    rcvlist_err - list for error frames masks
+    rcvlist_fil - list for mask/value filters
+    rcvlist_inv - list for mask/value filters (inverse semantic)
+    rcvlist_sff - list for single standard frame (SFF) entries
+
+  Additional procfs files in /proc/net/can
+
+    stats       - Socket CAN core statistics (rx/tx frames, match ratios, ...)
+    reset_stats - manual statistic reset
+    version     - prints the Socket CAN core version and the ABI version
+
+  5.3 writing own CAN protocol modules
+
+  To implement a new protocol in the protocol family PF_CAN a new
+  protocol has to be defined in include/linux/can.h .
+  The prototypes and definitions to use the Socket CAN core can be
+  accessed by including include/linux/can/core.h .
+  In addition to functions that register the CAN protocol and the
+  CAN device notifier chain there are functions to subscribe CAN
+  frames received by CAN interfaces and to send CAN frames:
+
+    can_rx_register   - subscribe CAN frames from a specific interface
+    can_rx_unregister - unsubscribe CAN frames from a specific interface
+    can_send          - transmit a CAN frame (optional with local loopback)
+
+  For details see the kerneldoc documentation in net/can/af_can.c or
+  the source code of net/can/raw.c or net/can/bcm.c .
+
+6. CAN network drivers
+----------------------
+
+  Writing a CAN network device driver is much easier than writing a
+  CAN character device driver. Similar to other known network device
+  drivers you mainly have to deal with:
+
+  - TX: Put the CAN frame from the socket buffer to the CAN controller.
+  - RX: Put the CAN frame from the CAN controller to the socket buffer.
+
+  See e.g. at Documentation/networking/netdevices.txt . The differences
+  for writing CAN network device driver are described below:
+
+  6.1 general settings
+
+    dev->type  = ARPHRD_CAN; /* the netdevice hardware type */
+    dev->flags = IFF_NOARP;  /* CAN has no arp */
+
+    dev->mtu   = sizeof(struct can_frame);
+
+  The struct can_frame is the payload of each socket buffer in the
+  protocol family PF_CAN.
+
+  6.2 loopback
+
+  As described in chapter 3.2 the CAN network device driver should
+  support a local loopback functionality. In this case the driver flag
+  IFF_LOOPBACK has to be set to cause the PF_CAN core to not perform the
+  loopback as fallback solution:
+
+    dev->flags = (IFF_NOARP | IFF_LOOPBACK);
+
+  6.3 CAN controller hardware filters
+
+  To reduce the interrupt load on deep embedded systems some CAN
+  controllers support the filtering of CAN IDs or ranges of CAN IDs.
+  These hardware filter capabilities vary from controller to
+  controller and have to be identified as not feasible in a multi-user
+  networking approach. The use of the very controller specific
+  hardware filters could make sense in a very dedicated use-case, as a
+  filter on driver level would affect all users in the multi-user
+  system. The high efficient filter sets inside the PF_CAN core allow
+  to set different multiple filters for each socket separately.
+  Therefore the use of hardware filters goes to the category 'handmade
+  tuning on deep embedded systems'. The author is running a MPC603e
+  @133MHz with four SJA1000 CAN controllers from 2002 under heavy bus
+  load without any problems ...
+
+  6.4 currently supported CAN hardware (May 2007)
+
+  On the project website http://developer.berlios.de/projects/socketcan
+  there are different drivers available:
+
+    vcan:    Virtual CAN interface driver (if no real hardware is available)
+    sja1000: Philips SJA1000 CAN controller (recommended)
+    i82527:  Intel i82527 CAN controller
+    mscan:   Motorola/Freescale CAN controller (e.g. inside SOC MPC5200)
+    slcan:   For a bunch of CAN adaptors that are attached via a
+             serial line ASCII protocol (for serial / USB adaptors)
+
+  Additionally the different CAN adaptors (ISA/PCI/PCMCIA/USB/Parport)
+  from PEAK Systemtechnik support the CAN netdevice driver model
+  since Linux driver v6.0: http://www.peak-system.com/linux/index.htm
+
+  Please check the Mailing Lists on the berlios OSS project website.
+
+  6.5 todo (May 2007)
+
+  The configuration interface for CAN network drivers is still an open
+  issue that has not been finalized in the socketcan project. Also the
+  idea of having a library module (candev.ko) that holds functions
+  that are needed by all CAN netdevices is not ready to ship.
+  Your contribution is welcome.
+
+7. Credits
+----------
+
+  Oliver Hartkopp (PF_CAN core, filters, drivers, bcm)
+  Urs Thuermann (PF_CAN core, kernel integration, socket interfaces, raw, vcan)
+  Jan Kizka (RT-SocketCAN core, Socket-API reconciliation)
+  Wolfgang Grandegger (RT-SocketCAN core & drivers, Raw Socket-API reviews)
+  Robert Schwebel (design reviews, PTXdist integration)
+  Marc Kleine-Budde (design reviews, Kernel 2.6 cleanups, drivers)
+  Benedikt Spranger (reviews)
+  Thomas Gleixner (LKML reviews, coding style, posting hints)
+  Andrey Volkov (kernel subtree structure, ioctls, mscan driver)
+  Matthias Brukner (first SJA1000 CAN netdevice implementation Q2/2003)
+  Klaus Hitschler (PEAK driver integration)
+  Uwe Koppe (CAN netdevices with PF_PACKET approach)
+  Michael Schulze (driver layer loopback requirement, RT CAN drivers review)
Index: net-2.6.24/Documentation/networking/00-INDEX
===================================================================
--- net-2.6.24.orig/Documentation/networking/00-INDEX	2007-09-24 17:53:07.000000000 +0200
+++ net-2.6.24/Documentation/networking/00-INDEX	2007-09-25 13:27:55.000000000 +0200
@@ -26,6 +26,8 @@
 	- info on the driver for Baycom style amateur radio modems
 bridge.txt
 	- where to get user space programs for ethernet bridging with Linux.
+can.txt
+	- documentation on CAN protocol family.
 comx.txt
 	- info on drivers for COMX line of synchronous serial adapters.
 cops.txt

--

[PATCH 0/7] CAN: New PF_CAN protocol family for 2.6.25, update

[Urs Thuermann]

Hello Dave, hello Patrick,

this patch series adds the PF_CAN protocol family for the
Controller Area Network.  Since our last post we have changed:

* Remove vcan_open() and vcan_stop().
* return NETDEV_TX_OK instead of 0.
* Add can_ prefix to some global vars.
* Remove all debug code completely.
* Cleanup of timer code.

This patch series applies against net-2.6.25 and is derived from Subversion
revision r560 of http://svn.berlios.de/svnroot/repos/socketcan.
It can be found in the directory
http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/<version>.

Urs Thuermann
Oliver Hartkopp


The changes in try #11 were:

* Fix a bug causing NULL pointer dereference when module autoloading fails.
* Initialize skb using skb_reset_{transport,network}_header().
* Use sock_alloc_send_skb() instead of alloc_skb().
* Adapt to changes in sk_alloc() parameter list.
* Rename some local variables for readability.

The changes in try #10 were:

* Rename our static debug variables to {can,raw,bcm,vcan}_debug.
* Use module_param_named() so that the module option names remain.
* Remove raw_poll() and bcm_poll() functions and use datagram_poll instead.
* Cleanup of can_addr union in sockaddr_can.
* Change type of echo module parameter to boolean.

The changes in try #9 were:

* Changes suggested by Arnaldo Carvalho de Melo:
  - Use gfp_any() instead of checking in_interrupt().
  - Don't kfree() the sk_protinfo field.
* Fixed licence text as pointed out by Yoshifuji Hideaki and Patrick McHardy.
* Added IFF_ECHO to include/linux/if.h and use that instead of IFF_LOOPBACK,
  as suggested by Eric W. Biederman.  IFF_LOOPBACK is only for the normal
  loopback interface.

The changes in try #8 were:

* Some changes in debug code, following suggestions from Joe Perches:
  - Remove dynamically allocated buffer for debug output.
  - Use kernel functions for hexdumps.
  - Don't interpret printf-style %-sequences in can_debug_cframe().
  - Specify the fixed argument "fmt" to DBG() macro and use
    GCC ## mechanism to remove , when args is empty.
* Removed CAN_RAW_USER and CAN_BCM_USER Kconfig options following a
  suggestion from Patrick.
* Prevent overflow in statistics calculation.
* Minor optimization.

The changes in try #7 were:

* Changes suggested by Patrick:
  - protect proto_tab[] by a lock.
  - add _rcu to some hlist traversals.
  - use printk_ratelimit() for module autoload failures.
  - make can_proto_unregister() and can_rx_unregister() return void.
  - use return value of can_proto_register() and can_rx_register()
    (this also removed a flaw in behavior of raw_bind() and raw_setsockopt()
     in case of failure to can_rx_register() their filters).
  - call kzalloc() with GFP_KERNEL in case NETDEV_REGISTER.
  - use round_jiffies() to calculate expiration times.
  - make some variables static and/or __read_mostly.
  - in can_create() check for net namespace before auto loading modules.
  - add build time check for struct sizes.
  - use skb_share_chack() in vcan.
  - fixed some comments.
* Typos in documentation as pointed out by Randy Dunlap and Bill Fink.

The changes in try #6 were:

* Update code to work with namespaces in net-2.6.24.
* Remove SET_MODULE_OWNER() from vcan.

The changes in try #5 were:

* Remove slab destructor from calls to kmem_cache_alloc().
* Add comments about types defined in can.h.
* Update comment on vcan loopback module parameter.
* Fix typo in documentation.

The changes in try #4 were:

* Change vcan network driver to use the new RTNL API, as suggested by
  Patrick.
* Revert our change to use skb->iif instead of skb->cb.  After
  discussion with Patrick and Jamal it turned out, our first
  implementation was correct.
* Use skb_tail_pointer() instead of skb->tail directly.
* Coding style changes to satisfy linux/scripts/checkpatch.pl.
* Minor changes for 64-bit-cleanliness.
* Minor cleanup of #include's

The changes in try #3 were:

* Use sbk->sk and skb->pkt_type instead of skb->cb to pass loopback
  flags and originating socket down to the driver and back to the
  receiving socket.  Thanks to Patrick McHardy for pointing out our
  wrong use of sbk->cb.
* Use skb->iif instead of skb->cb to pass receiving interface from
  raw_rcv() and bcm_rcv() up to raw_recvmsg() and bcm_recvmsg().
* Set skb->protocol when sending CAN frames to netdevices.
* Removed struct raw_opt and struct bcm_opt and integrated these
  directly into struct raw_sock and bcm_sock resp., like most other
  proto implementations do.
* We have found and fixed race conditions between raw_bind(),
  raw_{set,get}sockopt() and raw_notifier().  This resulted in
  - complete removal of our own notifier list infrastructure in
    af_can.c.  raw.c and bcm.c now use normal netdevice notifiers.
  - removal of ro->lock spinlock.  We use lock_sock(sk) now.
  - changed deletion of dev_rcv_lists, which are now marked for
    deletion in the netdevice notifier in af_can.c and are actually
    deleted when all entries have been deleted using can_rx_unregister().
* Follow changes in 2.6.22 (e.g. ktime_t timestamps in skb).
* Removed obsolete code from vcan.c, as pointed out by Stephen Hemminger.

The changes in try #2 were:

* reduced RCU callback overhead when deleting receiver lists (thx to
  feedback from Paul E. McKenney).
* eliminated some code duplication in net/can/proc.c.
* renamed slock-29 and sk_lock-29 to slock-AF_CAN and sk_lock-AF_CAN in
  net/core/sock.c
* added entry for can.txt in Documentation/networking/00-INDEX
* added error frame definitions in include/linux/can/error.h, which are to
  be used by CAN network drivers.
--

[PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

[-- Attachment #1: 05-can-vcan-driver.diff --]
[-- Type: text/plain, Size: 8265 bytes --]

This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 drivers/net/Makefile     |    1 
 drivers/net/can/Kconfig  |   25 ++++++
 drivers/net/can/Makefile |    5 +
 drivers/net/can/vcan.c   |  169 +++++++++++++++++++++++++++++++++++++++++++++++
 net/can/Kconfig          |    3 
 5 files changed, 203 insertions(+)

Index: net-2.6.25/drivers/net/Makefile
===================================================================
--- net-2.6.25.orig/drivers/net/Makefile	2007-11-16 14:50:12.000000000 +0100
+++ net-2.6.25/drivers/net/Makefile	2007-11-16 14:50:18.000000000 +0100
@@ -12,6 +12,7 @@
 obj-$(CONFIG_CHELSIO_T1) += chelsio/
 obj-$(CONFIG_CHELSIO_T3) += cxgb3/
 obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
 obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_ATL1) += atl1/
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: net-2.6.25/drivers/net/can/Kconfig
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.25/drivers/net/can/Kconfig	2007-11-16 14:50:18.000000000 +0100
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+	depends on CAN
+
+config CAN_VCAN
+	tristate "Virtual Local CAN Interface (vcan)"
+ 	depends on CAN
+	default N
+ 	---help---
+	  Similar to the network loopback devices, vcan offers a
+	  virtual local CAN interface.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called vcan.
+
+config CAN_DEBUG_DEVICES
+	bool "CAN devices debugging messages"
+	depends on CAN
+	default N
+	---help---
+	  Say Y here if you want the CAN device drivers to produce a bunch of
+	  debug messages to the system log.  Select this if you are having
+	  a problem with CAN support and want to see more of what is going
+	  on.
+
+endmenu
Index: net-2.6.25/drivers/net/can/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.25/drivers/net/can/Makefile	2007-11-16 14:50:18.000000000 +0100
@@ -0,0 +1,5 @@
+#
+#  Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN)		+= vcan.o
Index: net-2.6.25/drivers/net/can/vcan.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.25/drivers/net/can/vcan.c	2007-11-16 14:51:53.000000000 +0100
@@ -0,0 +1,169 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2, in which case the provisions of the
+ * GPL apply INSTEAD OF those given above.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/if_arp.h>
+#include <linux/if_ether.h>
+#include <linux/can.h>
+#include <net/rtnetlink.h>
+
+static __initdata const char banner[] =
+	KERN_INFO "vcan: Virtual CAN interface driver\n";
+
+MODULE_DESCRIPTION("virtual CAN interface");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
+
+
+/*
+ * CAN test feature:
+ * Enable the echo on driver level for testing the CAN core echo modes.
+ * See Documentation/networking/can.txt for details.
+ */
+
+static int echo; /* echo testing. Default: 0 (Off) */
+module_param(echo, bool, S_IRUGO);
+MODULE_PARM_DESC(echo, "Echo sent frames (for testing). Default: 0 (Off)");
+
+
+static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+
+	stats->rx_packets++;
+	stats->rx_bytes += skb->len;
+
+	skb->protocol  = htons(ETH_P_CAN);
+	skb->pkt_type  = PACKET_BROADCAST;
+	skb->dev       = dev;
+	skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	netif_rx(skb);
+}
+
+static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+	int loop;
+
+	stats->tx_packets++;
+	stats->tx_bytes += skb->len;
+
+	/* set flag whether this packet has to be looped back */
+	loop = skb->pkt_type == PACKET_LOOPBACK;
+
+	if (!echo) {
+		/* no echo handling available inside this driver */
+
+		if (loop) {
+			/*
+			 * only count the packets here, because the
+			 * CAN core already did the echo for us
+			 */
+			stats->rx_packets++;
+			stats->rx_bytes += skb->len;
+		}
+		kfree_skb(skb);
+		return NETDEV_TX_OK;
+	}
+
+	/* perform standard echo handling for CAN network interfaces */
+
+	if (loop) {
+		struct sock *srcsk = skb->sk;
+
+		skb = skb_share_check(skb, GFP_ATOMIC);
+		if (!skb)
+			return NETDEV_TX_OK;
+
+		/* receive with packet counting */
+		skb->sk = srcsk;
+		vcan_rx(skb, dev);
+	} else {
+		/* no looped packets => no counting */
+		kfree_skb(skb);
+	}
+	return NETDEV_TX_OK;
+}
+
+static void vcan_setup(struct net_device *dev)
+{
+	dev->type              = ARPHRD_CAN;
+	dev->mtu               = sizeof(struct can_frame);
+	dev->hard_header_len   = 0;
+	dev->addr_len          = 0;
+	dev->tx_queue_len      = 0;
+	dev->flags             = IFF_NOARP;
+
+	/* set flags according to driver capabilities */
+	if (echo)
+		dev->flags |= IFF_ECHO;
+
+	dev->hard_start_xmit   = vcan_tx;
+	dev->destructor        = free_netdev;
+}
+
+static struct rtnl_link_ops vcan_link_ops __read_mostly = {
+       .kind           = "vcan",
+       .setup          = vcan_setup,
+};
+
+static __init int vcan_init_module(void)
+{
+	printk(banner);
+
+	if (echo)
+		printk(KERN_INFO "vcan: enabled echo on driver level.\n");
+
+	return rtnl_link_register(&vcan_link_ops);
+}
+
+static __exit void vcan_cleanup_module(void)
+{
+	rtnl_link_unregister(&vcan_link_ops);
+}
+
+module_init(vcan_init_module);
+module_exit(vcan_cleanup_module);
Index: net-2.6.25/net/can/Kconfig
===================================================================
--- net-2.6.25.orig/net/can/Kconfig	2007-11-16 14:50:18.000000000 +0100
+++ net-2.6.25/net/can/Kconfig	2007-11-16 14:50:18.000000000 +0100
@@ -39,3 +39,6 @@
 	  You probably want to use the bcm socket in most cases where cyclic
 	  CAN messages are used on the bus (e.g. in automotive environments).
 	  To use the Broadcast Manager, use AF_CAN with protocol CAN_BCM.
+
+
+source "drivers/net/can/Kconfig"

--

[PATCH 0/7] CAN: New PF_CAN protocol family for 2.6.25

[Urs Thuermann]

Hello Dave, hello Patrick,

this patch series that adds the PF_CAN protocol family for the
Controller Area Network.  Since our last post we have changed:

* Fix a bug causing NULL pointer dereference when module autoloading fails.
* Initialize skb using skb_reset_{transport,network}_header().
* Use sock_alloc_send_skb() instead of alloc_skb().
* Adapt to changes in sk_alloc() parameter list.
* Rename some local variables for readability.

This patch series applies against net-2.6.25 and is derived from Subversion
revision r542 of http://svn.berlios.de/svnroot/repos/socketcan.
It can be found in the directory
http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/<version>.

Thanks very much for your work!

Best regards,

Urs Thuermann
Oliver Hartkopp



The changes in try #10 were:

* Rename our static debug variables to {can,raw,bcm,vcan}_debug.
* Use module_param_named() so that the module option names remain.
* Remove raw_poll() and bcm_poll() functions and use datagram_poll instead.
* Cleanup of can_addr union in sockaddr_can.
* Change type of echo module parameter to boolean.

The changes in try #9 were:

* Changes suggested by Arnaldo Carvalho de Melo:
  - Use gfp_any() instead of checking in_interrupt().
  - Don't kfree() the sk_protinfo field.
* Fixed licence text as pointed out by Yoshifuji Hideaki and Patrick McHardy.
* Added IFF_ECHO to include/linux/if.h and use that instead of IFF_LOOPBACK,
  as suggested by Eric W. Biederman.  IFF_LOOPBACK is only for the normal
  loopback interface.

The changes in try #8 were:

* Some changes in debug code, following suggestions from Joe Perches:
  - Remove dynamically allocated buffer for debug output.
  - Use kernel functions for hexdumps.
  - Don't interpret printf-style %-sequences in can_debug_cframe().
  - Specify the fixed argument "fmt" to DBG() macro and use
    GCC ## mechanism to remove , when args is empty.
* Removed CAN_RAW_USER and CAN_BCM_USER Kconfig options following a
  suggestion from Patrick.
* Prevent overflow in statistics calculation.
* Minor optimization.

The changes in try #7 were:

* Changes suggested by Patrick:
  - protect proto_tab[] by a lock.
  - add _rcu to some hlist traversals.
  - use printk_ratelimit() for module autoload failures.
  - make can_proto_unregister() and can_rx_unregister() return void.
  - use return value of can_proto_register() and can_rx_register()
    (this also removed a flaw in behavior of raw_bind() and raw_setsockopt()
     in case of failure to can_rx_register() their filters).
  - call kzalloc() with GFP_KERNEL in case NETDEV_REGISTER.
  - use round_jiffies() to calculate expiration times.
  - make some variables static and/or __read_mostly.
  - in can_create() check for net namespace before auto loading modules.
  - add build time check for struct sizes.
  - use skb_share_chack() in vcan.
  - fixed some comments.
* Typos in documentation as pointed out by Randy Dunlap and Bill Fink.

The changes in try #6 were:

* Update code to work with namespaces in net-2.6.24.
* Remove SET_MODULE_OWNER() from vcan.

The changes in try #5 were:

* Remove slab destructor from calls to kmem_cache_alloc().
* Add comments about types defined in can.h.
* Update comment on vcan loopback module parameter.
* Fix typo in documentation.

The changes in try #4 were:

* Change vcan network driver to use the new RTNL API, as suggested by
  Patrick.
* Revert our change to use skb->iif instead of skb->cb.  After
  discussion with Patrick and Jamal it turned out, our first
  implementation was correct.
* Use skb_tail_pointer() instead of skb->tail directly.
* Coding style changes to satisfy linux/scripts/checkpatch.pl.
* Minor changes for 64-bit-cleanliness.
* Minor cleanup of #include's

The changes in try #3 were:

* Use sbk->sk and skb->pkt_type instead of skb->cb to pass loopback
  flags and originating socket down to the driver and back to the
  receiving socket.  Thanks to Patrick McHardy for pointing out our
  wrong use of sbk->cb.
* Use skb->iif instead of skb->cb to pass receiving interface from
  raw_rcv() and bcm_rcv() up to raw_recvmsg() and bcm_recvmsg().
* Set skb->protocol when sending CAN frames to netdevices.
* Removed struct raw_opt and struct bcm_opt and integrated these
  directly into struct raw_sock and bcm_sock resp., like most other
  proto implementations do.
* We have found and fixed race conditions between raw_bind(),
  raw_{set,get}sockopt() and raw_notifier().  This resulted in
  - complete removal of our own notifier list infrastructure in
    af_can.c.  raw.c and bcm.c now use normal netdevice notifiers.
  - removal of ro->lock spinlock.  We use lock_sock(sk) now.
  - changed deletion of dev_rcv_lists, which are now marked for
    deletion in the netdevice notifier in af_can.c and are actually
    deleted when all entries have been deleted using can_rx_unregister().
* Follow changes in 2.6.22 (e.g. ktime_t timestamps in skb).
* Removed obsolete code from vcan.c, as pointed out by Stephen Hemminger.

The changes in try #2 were:

* reduced RCU callback overhead when deleting receiver lists (thx to
  feedback from Paul E. McKenney).
* eliminated some code duplication in net/can/proc.c.
* renamed slock-29 and sk_lock-29 to slock-AF_CAN and sk_lock-AF_CAN in
  net/core/sock.c
* added entry for can.txt in Documentation/networking/00-INDEX
* added error frame definitions in include/linux/can/error.h, which are to
  be used by CAN network drivers.
--

[PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

[-- Attachment #1: 05-can-vcan-driver.diff --]
[-- Type: text/plain, Size: 9053 bytes --]

This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 drivers/net/Makefile     |    1 
 drivers/net/can/Kconfig  |   25 +++++
 drivers/net/can/Makefile |    5 +
 drivers/net/can/vcan.c   |  207 +++++++++++++++++++++++++++++++++++++++++++++++
 net/can/Kconfig          |    3 
 5 files changed, 241 insertions(+)

Index: net-2.6.25/drivers/net/Makefile
===================================================================
--- net-2.6.25.orig/drivers/net/Makefile	2007-11-14 13:04:24.000000000 +0100
+++ net-2.6.25/drivers/net/Makefile	2007-11-14 13:04:54.000000000 +0100
@@ -12,6 +12,7 @@
 obj-$(CONFIG_CHELSIO_T1) += chelsio/
 obj-$(CONFIG_CHELSIO_T3) += cxgb3/
 obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
 obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_ATL1) += atl1/
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: net-2.6.25/drivers/net/can/Kconfig
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.25/drivers/net/can/Kconfig	2007-11-14 13:04:54.000000000 +0100
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+	depends on CAN
+
+config CAN_VCAN
+	tristate "Virtual Local CAN Interface (vcan)"
+ 	depends on CAN
+	default N
+ 	---help---
+	  Similar to the network loopback devices, vcan offers a
+	  virtual local CAN interface.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called vcan.
+
+config CAN_DEBUG_DEVICES
+	bool "CAN devices debugging messages"
+	depends on CAN
+	default N
+	---help---
+	  Say Y here if you want the CAN device drivers to produce a bunch of
+	  debug messages to the system log.  Select this if you are having
+	  a problem with CAN support and want to see more of what is going
+	  on.
+
+endmenu
Index: net-2.6.25/drivers/net/can/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.25/drivers/net/can/Makefile	2007-11-14 13:04:54.000000000 +0100
@@ -0,0 +1,5 @@
+#
+#  Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN)		+= vcan.o
Index: net-2.6.25/drivers/net/can/vcan.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.25/drivers/net/can/vcan.c	2007-11-14 13:04:54.000000000 +0100
@@ -0,0 +1,207 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2, in which case the provisions of the
+ * GPL apply INSTEAD OF those given above.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/if_arp.h>
+#include <linux/if_ether.h>
+#include <linux/can.h>
+#include <net/rtnetlink.h>
+
+static __initdata const char banner[] =
+	KERN_INFO "vcan: Virtual CAN interface driver\n";
+
+MODULE_DESCRIPTION("virtual CAN interface");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
+
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+static int vcan_debug;
+module_param_named(debug, vcan_debug, int, S_IRUGO);
+#endif
+
+/* To be moved to linux/can/dev.h */
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+#define DBG(fmt, args...)  (vcan_debug & 1 ? \
+				printk(KERN_DEBUG "vcan %s: " fmt, \
+				__func__, ##args) : 0)
+#else
+#define DBG(fmt, args...)
+#endif
+
+
+/*
+ * CAN test feature:
+ * Enable the echo on driver level for testing the CAN core echo modes.
+ * See Documentation/networking/can.txt for details.
+ */
+
+static int echo; /* echo testing. Default: 0 (Off) */
+module_param(echo, bool, S_IRUGO);
+MODULE_PARM_DESC(echo, "Echo sent frames (for testing). Default: 0 (Off)");
+
+
+static int vcan_open(struct net_device *dev)
+{
+	DBG("%s: interface up\n", dev->name);
+
+	netif_start_queue(dev);
+	return 0;
+}
+
+static int vcan_stop(struct net_device *dev)
+{
+	DBG("%s: interface down\n", dev->name);
+
+	netif_stop_queue(dev);
+	return 0;
+}
+
+static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+
+	stats->rx_packets++;
+	stats->rx_bytes += skb->len;
+
+	skb->protocol  = htons(ETH_P_CAN);
+	skb->pkt_type  = PACKET_BROADCAST;
+	skb->dev       = dev;
+	skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	DBG("received skbuff on interface %d\n", dev->ifindex);
+
+	netif_rx(skb);
+}
+
+static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+	int loop;
+
+	DBG("sending skbuff on interface %s\n", dev->name);
+
+	stats->tx_packets++;
+	stats->tx_bytes += skb->len;
+
+	/* set flag whether this packet has to be looped back */
+	loop = skb->pkt_type == PACKET_LOOPBACK;
+
+	if (!echo) {
+		/* no echo handling available inside this driver */
+
+		if (loop) {
+			/*
+			 * only count the packets here, because the
+			 * CAN core already did the echo for us
+			 */
+			stats->rx_packets++;
+			stats->rx_bytes += skb->len;
+		}
+		kfree_skb(skb);
+		return 0;
+	}
+
+	/* perform standard echo handling for CAN network interfaces */
+
+	if (loop) {
+		struct sock *srcsk = skb->sk;
+
+		skb = skb_share_check(skb, GFP_ATOMIC);
+		if (!skb)
+			return 0;
+
+		/* receive with packet counting */
+		skb->sk = srcsk;
+		vcan_rx(skb, dev);
+	} else {
+		/* no looped packets => no counting */
+		kfree_skb(skb);
+	}
+	return 0;
+}
+
+static void vcan_setup(struct net_device *dev)
+{
+	DBG("dev %s\n", dev->name);
+
+	dev->type              = ARPHRD_CAN;
+	dev->mtu               = sizeof(struct can_frame);
+	dev->hard_header_len   = 0;
+	dev->addr_len          = 0;
+	dev->tx_queue_len      = 0;
+	dev->flags             = IFF_NOARP;
+
+	/* set flags according to driver capabilities */
+	if (echo)
+		dev->flags |= IFF_ECHO;
+
+	dev->open              = vcan_open;
+	dev->stop              = vcan_stop;
+	dev->hard_start_xmit   = vcan_tx;
+	dev->destructor        = free_netdev;
+}
+
+static struct rtnl_link_ops vcan_link_ops __read_mostly = {
+       .kind           = "vcan",
+       .setup          = vcan_setup,
+};
+
+static __init int vcan_init_module(void)
+{
+	printk(banner);
+
+	if (echo)
+		printk(KERN_INFO "vcan: enabled echo on driver level.\n");
+
+	return rtnl_link_register(&vcan_link_ops);
+}
+
+static __exit void vcan_cleanup_module(void)
+{
+	rtnl_link_unregister(&vcan_link_ops);
+}
+
+module_init(vcan_init_module);
+module_exit(vcan_cleanup_module);
Index: net-2.6.25/net/can/Kconfig
===================================================================
--- net-2.6.25.orig/net/can/Kconfig	2007-11-14 13:04:52.000000000 +0100
+++ net-2.6.25/net/can/Kconfig	2007-11-14 13:04:54.000000000 +0100
@@ -47,3 +47,6 @@
 	  Say Y here if you want the CAN core to produce a bunch of debug
 	  messages.  Select this if you are having a problem with CAN
 	  support and want to see more of what is going on.
+
+
+source "drivers/net/can/Kconfig"

--

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Urs Thuermann wrote:
> +static int vcan_open(struct net_device *dev)
> +{
> +	DBG("%s: interface up\n", dev->name);
> +
> +	netif_start_queue(dev);
> +	return 0;
> +}
> +
> +static int vcan_stop(struct net_device *dev)
> +{
> +	DBG("%s: interface down\n", dev->name);
> +
> +	netif_stop_queue(dev);
> +	return 0;
> +}


These two functions look unnecessary, there's no need to manage
the queue for pure software devices.

> +static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
> +{
> +	struct net_device_stats *stats = &dev->stats;
> +	int loop;
> +
> +	DBG("sending skbuff on interface %s\n", dev->name);
> +
> +	stats->tx_packets++;
> +	stats->tx_bytes += skb->len;
> +
> +	/* set flag whether this packet has to be looped back */
> +	loop = skb->pkt_type == PACKET_LOOPBACK;
> +
> +	if (!echo) {
> +		/* no echo handling available inside this driver */
> +
> +		if (loop) {
> +			/*
> +			 * only count the packets here, because the
> +			 * CAN core already did the echo for us
> +			 */
> +			stats->rx_packets++;
> +			stats->rx_bytes += skb->len;
> +		}
> +		kfree_skb(skb);
> +		return 0;

Please use the NETDEV_TX codes.

Besides these minor issues, looks fine.

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

Patrick McHardy <kaber@trash.net> writes:

> > +static int vcan_open(struct net_device *dev)

> > +static int vcan_stop(struct net_device *dev)

> These two functions look unnecessary, there's no need to manage
> the queue for pure software devices.

OK, removed.

> Please use the NETDEV_TX codes.

OK, replaced return 0 by NETDEV_TX_OK.

The new patch is below.

urs



This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 drivers/net/Makefile     |    1 
 drivers/net/can/Kconfig  |   25 ++++++
 drivers/net/can/Makefile |    5 +
 drivers/net/can/vcan.c   |  189 +++++++++++++++++++++++++++++++++++++++++++++++
 net/can/Kconfig          |    3 
 5 files changed, 223 insertions(+)

Index: net-2.6.25/drivers/net/Makefile
===================================================================
--- net-2.6.25.orig/drivers/net/Makefile	2007-11-14 13:04:24.000000000 +0100
+++ net-2.6.25/drivers/net/Makefile	2007-11-14 13:04:54.000000000 +0100
@@ -12,6 +12,7 @@
 obj-$(CONFIG_CHELSIO_T1) += chelsio/
 obj-$(CONFIG_CHELSIO_T3) += cxgb3/
 obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
 obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_ATL1) += atl1/
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: net-2.6.25/drivers/net/can/Kconfig
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.25/drivers/net/can/Kconfig	2007-11-14 13:04:54.000000000 +0100
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+	depends on CAN
+
+config CAN_VCAN
+	tristate "Virtual Local CAN Interface (vcan)"
+ 	depends on CAN
+	default N
+ 	---help---
+	  Similar to the network loopback devices, vcan offers a
+	  virtual local CAN interface.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called vcan.
+
+config CAN_DEBUG_DEVICES
+	bool "CAN devices debugging messages"
+	depends on CAN
+	default N
+	---help---
+	  Say Y here if you want the CAN device drivers to produce a bunch of
+	  debug messages to the system log.  Select this if you are having
+	  a problem with CAN support and want to see more of what is going
+	  on.
+
+endmenu
Index: net-2.6.25/drivers/net/can/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.25/drivers/net/can/Makefile	2007-11-14 13:04:54.000000000 +0100
@@ -0,0 +1,5 @@
+#
+#  Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN)		+= vcan.o
Index: net-2.6.25/drivers/net/can/vcan.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.25/drivers/net/can/vcan.c	2007-11-14 14:17:43.000000000 +0100
@@ -0,0 +1,189 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2, in which case the provisions of the
+ * GPL apply INSTEAD OF those given above.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/if_arp.h>
+#include <linux/if_ether.h>
+#include <linux/can.h>
+#include <net/rtnetlink.h>
+
+static __initdata const char banner[] =
+	KERN_INFO "vcan: Virtual CAN interface driver\n";
+
+MODULE_DESCRIPTION("virtual CAN interface");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
+
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+static int vcan_debug;
+module_param_named(debug, vcan_debug, int, S_IRUGO);
+#endif
+
+/* To be moved to linux/can/dev.h */
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+#define DBG(fmt, args...)  (vcan_debug & 1 ? \
+				printk(KERN_DEBUG "vcan %s: " fmt, \
+				__func__, ##args) : 0)
+#else
+#define DBG(fmt, args...)
+#endif
+
+
+/*
+ * CAN test feature:
+ * Enable the echo on driver level for testing the CAN core echo modes.
+ * See Documentation/networking/can.txt for details.
+ */
+
+static int echo; /* echo testing. Default: 0 (Off) */
+module_param(echo, bool, S_IRUGO);
+MODULE_PARM_DESC(echo, "Echo sent frames (for testing). Default: 0 (Off)");
+
+
+static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+
+	stats->rx_packets++;
+	stats->rx_bytes += skb->len;
+
+	skb->protocol  = htons(ETH_P_CAN);
+	skb->pkt_type  = PACKET_BROADCAST;
+	skb->dev       = dev;
+	skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	DBG("received skbuff on interface %d\n", dev->ifindex);
+
+	netif_rx(skb);
+}
+
+static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+	int loop;
+
+	DBG("sending skbuff on interface %s\n", dev->name);
+
+	stats->tx_packets++;
+	stats->tx_bytes += skb->len;
+
+	/* set flag whether this packet has to be looped back */
+	loop = skb->pkt_type == PACKET_LOOPBACK;
+
+	if (!echo) {
+		/* no echo handling available inside this driver */
+
+		if (loop) {
+			/*
+			 * only count the packets here, because the
+			 * CAN core already did the echo for us
+			 */
+			stats->rx_packets++;
+			stats->rx_bytes += skb->len;
+		}
+		kfree_skb(skb);
+		return NETDEV_TX_OK;
+	}
+
+	/* perform standard echo handling for CAN network interfaces */
+
+	if (loop) {
+		struct sock *srcsk = skb->sk;
+
+		skb = skb_share_check(skb, GFP_ATOMIC);
+		if (!skb)
+			return 0;
+
+		/* receive with packet counting */
+		skb->sk = srcsk;
+		vcan_rx(skb, dev);
+	} else {
+		/* no looped packets => no counting */
+		kfree_skb(skb);
+	}
+	return NETDEV_TX_OK;
+}
+
+static void vcan_setup(struct net_device *dev)
+{
+	DBG("dev %s\n", dev->name);
+
+	dev->type              = ARPHRD_CAN;
+	dev->mtu               = sizeof(struct can_frame);
+	dev->hard_header_len   = 0;
+	dev->addr_len          = 0;
+	dev->tx_queue_len      = 0;
+	dev->flags             = IFF_NOARP;
+
+	/* set flags according to driver capabilities */
+	if (echo)
+		dev->flags |= IFF_ECHO;
+
+	dev->hard_start_xmit   = vcan_tx;
+	dev->destructor        = free_netdev;
+}
+
+static struct rtnl_link_ops vcan_link_ops __read_mostly = {
+       .kind           = "vcan",
+       .setup          = vcan_setup,
+};
+
+static __init int vcan_init_module(void)
+{
+	printk(banner);
+
+	if (echo)
+		printk(KERN_INFO "vcan: enabled echo on driver level.\n");
+
+	return rtnl_link_register(&vcan_link_ops);
+}
+
+static __exit void vcan_cleanup_module(void)
+{
+	rtnl_link_unregister(&vcan_link_ops);
+}
+
+module_init(vcan_init_module);
+module_exit(vcan_cleanup_module);
Index: net-2.6.25/net/can/Kconfig
===================================================================
--- net-2.6.25.orig/net/can/Kconfig	2007-11-14 13:04:52.000000000 +0100
+++ net-2.6.25/net/can/Kconfig	2007-11-14 13:04:54.000000000 +0100
@@ -47,3 +47,6 @@
 	  Say Y here if you want the CAN core to produce a bunch of debug
 	  messages.  Select this if you are having a problem with CAN
 	  support and want to see more of what is going on.
+
+
+source "drivers/net/can/Kconfig"

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Urs Thuermann wrote:
> The new patch is below.


Thanks. I'll look over the other patches later.

[PATCH 0/7] CAN: Add new PF_CAN protocol family, try #10

[Urs Thuermann]

Hello Dave, hello Patrick,

this is the tenth post of the patch series that adds the PF_CAN
protocol family for the Controller Area Network.

We've fixed some cosmetic issues as remarked by Arnaldo:

* Rename our static debug variables to {can,raw,bcm,vcan}_debug.
* Use module_param_named() so that the module option names remain.
* Remove raw_poll() and bcm_poll() functions and use datagram_poll instead.
* Cleanup of can_addr union in sockaddr_can.
* Change type of echo module parameter to boolean.

Thanks to all reviewers for the constructive feedback!

Regards,
urs



The changes in try #9 were:

* Changes suggested by Arnaldo Carvalho de Melo:
  - Use gfp_any() instead of checking in_interrupt().
  - Don't kfree() the sk_protinfo field.
* Fixed licence text as pointed out by Yoshifuji Hideaki and Patrick McHardy.
* Added IFF_ECHO to include/linux/if.h and use that instead of IFF_LOOPBACK,
  as suggested by Eric W. Biederman.  IFF_LOOPBACK is only for the normal
  loopback interface.

The changes in try #8 were:

* Some changes in debug code, following suggestions from Joe Perches:
  - Remove dynamically allocated buffer for debug output.
  - Use kernel functions for hexdumps.
  - Don't interpret printf-style %-sequences in can_debug_cframe().
  - Specify the fixed argument "fmt" to DBG() macro and use
    GCC ## mechanism to remove , when args is empty.
* Removed CAN_RAW_USER and CAN_BCM_USER Kconfig options following a
  suggestion from Patrick.
* Prevent overflow in statistics calculation.
* Minor optimization.

The changes in try #7 were:

* Changes suggested by Patrick:
  - protect proto_tab[] by a lock.
  - add _rcu to some hlist traversals.
  - use printk_ratelimit() for module autoload failures.
  - make can_proto_unregister() and can_rx_unregister() return void.
  - use return value of can_proto_register() and can_rx_register()
    (this also removed a flaw in behavior of raw_bind() and raw_setsockopt()
     in case of failure to can_rx_register() their filters).
  - call kzalloc() with GFP_KERNEL in case NETDEV_REGISTER.
  - use round_jiffies() to calculate expiration times.
  - make some variables static and/or __read_mostly.
  - in can_create() check for net namespace before auto loading modules.
  - add build time check for struct sizes.
  - use skb_share_chack() in vcan.
  - fixed some comments.
* Typos in documentation as pointed out by Randy Dunlap and Bill Fink.

The changes in try #6 were:

* Update code to work with namespaces in net-2.6.24.
* Remove SET_MODULE_OWNER() from vcan.

The changes in try #5 were:

* Remove slab destructor from calls to kmem_cache_alloc().
* Add comments about types defined in can.h.
* Update comment on vcan loopback module parameter.
* Fix typo in documentation.

The changes in try #4 were:

* Change vcan network driver to use the new RTNL API, as suggested by
  Patrick.
* Revert our change to use skb->iif instead of skb->cb.  After
  discussion with Patrick and Jamal it turned out, our first
  implementation was correct.
* Use skb_tail_pointer() instead of skb->tail directly.
* Coding style changes to satisfy linux/scripts/checkpatch.pl.
* Minor changes for 64-bit-cleanliness.
* Minor cleanup of #include's

The changes in try #3 were:

* Use sbk->sk and skb->pkt_type instead of skb->cb to pass loopback
  flags and originating socket down to the driver and back to the
  receiving socket.  Thanks to Patrick McHardy for pointing out our
  wrong use of sbk->cb.
* Use skb->iif instead of skb->cb to pass receiving interface from
  raw_rcv() and bcm_rcv() up to raw_recvmsg() and bcm_recvmsg().
* Set skb->protocol when sending CAN frames to netdevices.
* Removed struct raw_opt and struct bcm_opt and integrated these
  directly into struct raw_sock and bcm_sock resp., like most other
  proto implementations do.
* We have found and fixed race conditions between raw_bind(),
  raw_{set,get}sockopt() and raw_notifier().  This resulted in
  - complete removal of our own notifier list infrastructure in
    af_can.c.  raw.c and bcm.c now use normal netdevice notifiers.
  - removal of ro->lock spinlock.  We use lock_sock(sk) now.
  - changed deletion of dev_rcv_lists, which are now marked for
    deletion in the netdevice notifier in af_can.c and are actually
    deleted when all entries have been deleted using can_rx_unregister().
* Follow changes in 2.6.22 (e.g. ktime_t timestamps in skb).
* Removed obsolete code from vcan.c, as pointed out by Stephen Hemminger.

The changes in try #2 were:

* reduced RCU callback overhead when deleting receiver lists (thx to
  feedback from Paul E. McKenney).
* eliminated some code duplication in net/can/proc.c.
* renamed slock-29 and sk_lock-29 to slock-AF_CAN and sk_lock-AF_CAN in
  net/core/sock.c
* added entry for can.txt in Documentation/networking/00-INDEX
* added error frame definitions in include/linux/can/error.h, which are to
  be used by CAN network drivers.


This patch series applies against net-2.6.24 and is derived from Subversion
revision r522 of http://svn.berlios.de/svnroot/repos/socketcan.
It can be found in the directory
http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/<version>.

Thanks very much for your work!

Best regards,

Urs Thuermann
Oliver Hartkopp
--

[PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

[-- Attachment #1: 05-can-vcan-driver.diff --]
[-- Type: text/plain, Size: 9053 bytes --]

This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 drivers/net/Makefile     |    1 
 drivers/net/can/Kconfig  |   25 +++++
 drivers/net/can/Makefile |    5 +
 drivers/net/can/vcan.c   |  207 +++++++++++++++++++++++++++++++++++++++++++++++
 net/can/Kconfig          |    3 
 5 files changed, 241 insertions(+)

Index: net-2.6.24/drivers/net/Makefile
===================================================================
--- net-2.6.24.orig/drivers/net/Makefile	2007-10-05 11:08:03.000000000 +0200
+++ net-2.6.24/drivers/net/Makefile	2007-10-05 11:17:41.000000000 +0200
@@ -12,6 +12,7 @@
 obj-$(CONFIG_CHELSIO_T1) += chelsio/
 obj-$(CONFIG_CHELSIO_T3) += cxgb3/
 obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
 obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_ATL1) += atl1/
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: net-2.6.24/drivers/net/can/Kconfig
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/drivers/net/can/Kconfig	2007-10-05 11:17:41.000000000 +0200
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+	depends on CAN
+
+config CAN_VCAN
+	tristate "Virtual Local CAN Interface (vcan)"
+ 	depends on CAN
+	default N
+ 	---help---
+	  Similar to the network loopback devices, vcan offers a
+	  virtual local CAN interface.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called vcan.
+
+config CAN_DEBUG_DEVICES
+	bool "CAN devices debugging messages"
+	depends on CAN
+	default N
+	---help---
+	  Say Y here if you want the CAN device drivers to produce a bunch of
+	  debug messages to the system log.  Select this if you are having
+	  a problem with CAN support and want to see more of what is going
+	  on.
+
+endmenu
Index: net-2.6.24/drivers/net/can/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/drivers/net/can/Makefile	2007-10-05 11:17:41.000000000 +0200
@@ -0,0 +1,5 @@
+#
+#  Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN)		+= vcan.o
Index: net-2.6.24/drivers/net/can/vcan.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/drivers/net/can/vcan.c	2007-10-05 11:17:41.000000000 +0200
@@ -0,0 +1,207 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2, in which case the provisions of the
+ * GPL apply INSTEAD OF those given above.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/if_arp.h>
+#include <linux/if_ether.h>
+#include <linux/can.h>
+#include <net/rtnetlink.h>
+
+static __initdata const char banner[] =
+	KERN_INFO "vcan: Virtual CAN interface driver\n";
+
+MODULE_DESCRIPTION("virtual CAN interface");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
+
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+static int vcan_debug;
+module_param_named(debug, vcan_debug, int, S_IRUGO);
+#endif
+
+/* To be moved to linux/can/dev.h */
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+#define DBG(fmt, args...)  (vcan_debug & 1 ? \
+				printk(KERN_DEBUG "vcan %s: " fmt, \
+				__func__, ##args) : 0)
+#else
+#define DBG(fmt, args...)
+#endif
+
+
+/*
+ * CAN test feature:
+ * Enable the echo on driver level for testing the CAN core echo modes.
+ * See Documentation/networking/can.txt for details.
+ */
+
+static int echo; /* echo testing. Default: 0 (Off) */
+module_param(echo, bool, S_IRUGO);
+MODULE_PARM_DESC(echo, "Echo sent frames (for testing). Default: 0 (Off)");
+
+
+static int vcan_open(struct net_device *dev)
+{
+	DBG("%s: interface up\n", dev->name);
+
+	netif_start_queue(dev);
+	return 0;
+}
+
+static int vcan_stop(struct net_device *dev)
+{
+	DBG("%s: interface down\n", dev->name);
+
+	netif_stop_queue(dev);
+	return 0;
+}
+
+static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+
+	stats->rx_packets++;
+	stats->rx_bytes += skb->len;
+
+	skb->protocol  = htons(ETH_P_CAN);
+	skb->pkt_type  = PACKET_BROADCAST;
+	skb->dev       = dev;
+	skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	DBG("received skbuff on interface %d\n", dev->ifindex);
+
+	netif_rx(skb);
+}
+
+static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+	int loop;
+
+	DBG("sending skbuff on interface %s\n", dev->name);
+
+	stats->tx_packets++;
+	stats->tx_bytes += skb->len;
+
+	/* set flag whether this packet has to be looped back */
+	loop = skb->pkt_type == PACKET_LOOPBACK;
+
+	if (!echo) {
+		/* no echo handling available inside this driver */
+
+		if (loop) {
+			/*
+			 * only count the packets here, because the
+			 * CAN core already did the echo for us
+			 */
+			stats->rx_packets++;
+			stats->rx_bytes += skb->len;
+		}
+		kfree_skb(skb);
+		return 0;
+	}
+
+	/* perform standard echo handling for CAN network interfaces */
+
+	if (loop) {
+		struct sock *srcsk = skb->sk;
+
+		skb = skb_share_check(skb, GFP_ATOMIC);
+		if (!skb)
+			return 0;
+
+		/* receive with packet counting */
+		skb->sk = srcsk;
+		vcan_rx(skb, dev);
+	} else {
+		/* no looped packets => no counting */
+		kfree_skb(skb);
+	}
+	return 0;
+}
+
+static void vcan_setup(struct net_device *dev)
+{
+	DBG("dev %s\n", dev->name);
+
+	dev->type              = ARPHRD_CAN;
+	dev->mtu               = sizeof(struct can_frame);
+	dev->hard_header_len   = 0;
+	dev->addr_len          = 0;
+	dev->tx_queue_len      = 0;
+	dev->flags             = IFF_NOARP;
+
+	/* set flags according to driver capabilities */
+	if (echo)
+		dev->flags |= IFF_ECHO;
+
+	dev->open              = vcan_open;
+	dev->stop              = vcan_stop;
+	dev->hard_start_xmit   = vcan_tx;
+	dev->destructor        = free_netdev;
+}
+
+static struct rtnl_link_ops vcan_link_ops __read_mostly = {
+       .kind           = "vcan",
+       .setup          = vcan_setup,
+};
+
+static __init int vcan_init_module(void)
+{
+	printk(banner);
+
+	if (echo)
+		printk(KERN_INFO "vcan: enabled echo on driver level.\n");
+
+	return rtnl_link_register(&vcan_link_ops);
+}
+
+static __exit void vcan_cleanup_module(void)
+{
+	rtnl_link_unregister(&vcan_link_ops);
+}
+
+module_init(vcan_init_module);
+module_exit(vcan_cleanup_module);
Index: net-2.6.24/net/can/Kconfig
===================================================================
--- net-2.6.24.orig/net/can/Kconfig	2007-10-05 11:17:28.000000000 +0200
+++ net-2.6.24/net/can/Kconfig	2007-10-05 11:18:19.000000000 +0200
@@ -47,3 +47,6 @@
 	  Say Y here if you want the CAN core to produce a bunch of debug
 	  messages.  Select this if you are having a problem with CAN
 	  support and want to see more of what is going on.
+
+
+source "drivers/net/can/Kconfig"

--

[PATCH 0/7] CAN: Add new PF_CAN protocol family, try #9

[Urs Thuermann]

Hello Dave, hello Patrick,

this is the nineth post of the patch series that adds the PF_CAN
protocol family for the Controller Area Network.

Since our last post we have changed the following:

* Changes suggested by Arnaldo Carvalho de Melo:
  - Use gfp_any() instead of checking in_interrupt().
  - Don't kfree() the sk_protinfo field.
* Fixed licence text as pointed out by Yoshifuji Hideaki and Patrick McHardy.
* Added IFF_ECHO to include/linux/if.h and use that instead of IFF_LOOPBACK,
  as suggested by Eric W. Biederman.  IFF_LOOPBACK is only for the normal
  loopback interface.

The changes in try #8 were:

* Some changes in debug code, following suggestions from Joe Perches:
  - Remove dynamically allocated buffer for debug output.
  - Use kernel functions for hexdumps.
  - Don't interpret printf-style %-sequences in can_debug_cframe().
  - Specify the fixed argument "fmt" to DBG() macro and use
    GCC ## mechanism to remove , when args is empty.
* Removed CAN_RAW_USER and CAN_BCM_USER Kconfig options following a
  suggestion from Patrick.
* Prevent overflow in statistics calculation.
* Minor optimization.

The changes in try #7 were:

* Changes suggested by Patrick:
  - protect proto_tab[] by a lock.
  - add _rcu to some hlist traversals.
  - use printk_ratelimit() for module autoload failures.
  - make can_proto_unregister() and can_rx_unregister() return void.
  - use return value of can_proto_register() and can_rx_register()
    (this also removed a flaw in behavior of raw_bind() and raw_setsockopt()
     in case of failure to can_rx_register() their filters).
  - call kzalloc() with GFP_KERNEL in case NETDEV_REGISTER.
  - use round_jiffies() to calculate expiration times.
  - make some variables static and/or __read_mostly.
  - in can_create() check for net namespace before auto loading modules.
  - add build time check for struct sizes.
  - use skb_share_chack() in vcan.
  - fixed some comments.
* Typos in documentation as pointed out by Randy Dunlap and Bill Fink.

The changes in try #6 were:

* Update code to work with namespaces in net-2.6.24.
* Remove SET_MODULE_OWNER() from vcan.

The changes in try #5 were:

* Remove slab destructor from calls to kmem_cache_alloc().
* Add comments about types defined in can.h.
* Update comment on vcan loopback module parameter.
* Fix typo in documentation.

The changes in try #4 were:

* Change vcan network driver to use the new RTNL API, as suggested by
  Patrick.
* Revert our change to use skb->iif instead of skb->cb.  After
  discussion with Patrick and Jamal it turned out, our first
  implementation was correct.
* Use skb_tail_pointer() instead of skb->tail directly.
* Coding style changes to satisfy linux/scripts/checkpatch.pl.
* Minor changes for 64-bit-cleanliness.
* Minor cleanup of #include's

The changes in try #3 were:

* Use sbk->sk and skb->pkt_type instead of skb->cb to pass loopback
  flags and originating socket down to the driver and back to the
  receiving socket.  Thanks to Patrick McHardy for pointing out our
  wrong use of sbk->cb.
* Use skb->iif instead of skb->cb to pass receiving interface from
  raw_rcv() and bcm_rcv() up to raw_recvmsg() and bcm_recvmsg().
* Set skb->protocol when sending CAN frames to netdevices.
* Removed struct raw_opt and struct bcm_opt and integrated these
  directly into struct raw_sock and bcm_sock resp., like most other
  proto implementations do.
* We have found and fixed race conditions between raw_bind(),
  raw_{set,get}sockopt() and raw_notifier().  This resulted in
  - complete removal of our own notifier list infrastructure in
    af_can.c.  raw.c and bcm.c now use normal netdevice notifiers.
  - removal of ro->lock spinlock.  We use lock_sock(sk) now.
  - changed deletion of dev_rcv_lists, which are now marked for
    deletion in the netdevice notifier in af_can.c and are actually
    deleted when all entries have been deleted using can_rx_unregister().
* Follow changes in 2.6.22 (e.g. ktime_t timestamps in skb).
* Removed obsolete code from vcan.c, as pointed out by Stephen Hemminger.

The changes in try #2 were:

* reduced RCU callback overhead when deleting receiver lists (thx to
  feedback from Paul E. McKenney).
* eliminated some code duplication in net/can/proc.c.
* renamed slock-29 and sk_lock-29 to slock-AF_CAN and sk_lock-AF_CAN in
  net/core/sock.c
* added entry for can.txt in Documentation/networking/00-INDEX
* added error frame definitions in include/linux/can/error.h, which are to
  be used by CAN network drivers.


This patch series applies against net-2.6.24 and is derived from Subversion
revision r511 of http://svn.berlios.de/svnroot/repos/socketcan.
It can be found in the directory
http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/<version>.

Thanks very much for your work!

Best regards,

Urs Thuermann
Oliver Hartkopp
--

[PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

[-- Attachment #1: 05-can-vcan-driver.diff --]
[-- Type: text/plain, Size: 9042 bytes --]

This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 drivers/net/Makefile     |    1 
 drivers/net/can/Kconfig  |   25 +++++
 drivers/net/can/Makefile |    5 +
 drivers/net/can/vcan.c   |  207 +++++++++++++++++++++++++++++++++++++++++++++++
 net/can/Kconfig          |    3 
 5 files changed, 241 insertions(+)

Index: net-2.6.24/drivers/net/Makefile
===================================================================
--- net-2.6.24.orig/drivers/net/Makefile	2007-09-20 23:46:01.000000000 +0200
+++ net-2.6.24/drivers/net/Makefile	2007-10-02 12:03:30.000000000 +0200
@@ -12,6 +12,7 @@
 obj-$(CONFIG_CHELSIO_T1) += chelsio/
 obj-$(CONFIG_CHELSIO_T3) += cxgb3/
 obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
 obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_ATL1) += atl1/
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: net-2.6.24/drivers/net/can/Kconfig
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/drivers/net/can/Kconfig	2007-10-02 12:03:30.000000000 +0200
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+	depends on CAN
+
+config CAN_VCAN
+	tristate "Virtual Local CAN Interface (vcan)"
+ 	depends on CAN
+	default N
+ 	---help---
+	  Similar to the network loopback devices, vcan offers a
+	  virtual local CAN interface.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called vcan.
+
+config CAN_DEBUG_DEVICES
+	bool "CAN devices debugging messages"
+	depends on CAN
+	default N
+	---help---
+	  Say Y here if you want the CAN device drivers to produce a bunch of
+	  debug messages to the system log.  Select this if you are having
+	  a problem with CAN support and want to see more of what is going
+	  on.
+
+endmenu
Index: net-2.6.24/drivers/net/can/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/drivers/net/can/Makefile	2007-10-02 12:03:30.000000000 +0200
@@ -0,0 +1,5 @@
+#
+#  Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN)		+= vcan.o
Index: net-2.6.24/drivers/net/can/vcan.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/drivers/net/can/vcan.c	2007-10-02 12:03:30.000000000 +0200
@@ -0,0 +1,207 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2, in which case the provisions of the
+ * GPL apply INSTEAD OF those given above.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/if_arp.h>
+#include <linux/if_ether.h>
+#include <linux/can.h>
+#include <net/rtnetlink.h>
+
+static __initdata const char banner[] =
+	KERN_INFO "vcan: Virtual CAN interface driver\n";
+
+MODULE_DESCRIPTION("virtual CAN interface");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
+
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+static int debug;
+module_param(debug, int, S_IRUGO);
+#endif
+
+/* To be moved to linux/can/dev.h */
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+#define DBG(fmt, args...)  (debug & 1 ? \
+				printk(KERN_DEBUG "vcan %s: " fmt, \
+				__func__, ##args) : 0)
+#else
+#define DBG(fmt, args...)
+#endif
+
+
+/*
+ * CAN test feature:
+ * Enable the echo on driver level for testing the CAN core echo modes.
+ * See Documentation/networking/can.txt for details.
+ */
+
+static int echo; /* echo testing. Default: 0 (Off) */
+module_param(echo, int, S_IRUGO);
+MODULE_PARM_DESC(echo, "Echo sent frames (for testing). Default: 0 (Off)");
+
+
+static int vcan_open(struct net_device *dev)
+{
+	DBG("%s: interface up\n", dev->name);
+
+	netif_start_queue(dev);
+	return 0;
+}
+
+static int vcan_stop(struct net_device *dev)
+{
+	DBG("%s: interface down\n", dev->name);
+
+	netif_stop_queue(dev);
+	return 0;
+}
+
+static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+
+	stats->rx_packets++;
+	stats->rx_bytes += skb->len;
+
+	skb->protocol  = htons(ETH_P_CAN);
+	skb->pkt_type  = PACKET_BROADCAST;
+	skb->dev       = dev;
+	skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	DBG("received skbuff on interface %d\n", dev->ifindex);
+
+	netif_rx(skb);
+}
+
+static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+	int loop;
+
+	DBG("sending skbuff on interface %s\n", dev->name);
+
+	stats->tx_packets++;
+	stats->tx_bytes += skb->len;
+
+	/* set flag whether this packet has to be looped back */
+	loop = skb->pkt_type == PACKET_LOOPBACK;
+
+	if (!echo) {
+		/* no echo handling available inside this driver */
+
+		if (loop) {
+			/*
+			 * only count the packets here, because the
+			 * CAN core already did the echo for us
+			 */
+			stats->rx_packets++;
+			stats->rx_bytes += skb->len;
+		}
+		kfree_skb(skb);
+		return 0;
+	}
+
+	/* perform standard echo handling for CAN network interfaces */
+
+	if (loop) {
+		struct sock *srcsk = skb->sk;
+
+		skb = skb_share_check(skb, GFP_ATOMIC);
+		if (!skb)
+			return 0;
+
+		/* receive with packet counting */
+		skb->sk = srcsk;
+		vcan_rx(skb, dev);
+	} else {
+		/* no looped packets => no counting */
+		kfree_skb(skb);
+	}
+	return 0;
+}
+
+static void vcan_setup(struct net_device *dev)
+{
+	DBG("dev %s\n", dev->name);
+
+	dev->type              = ARPHRD_CAN;
+	dev->mtu               = sizeof(struct can_frame);
+	dev->hard_header_len   = 0;
+	dev->addr_len          = 0;
+	dev->tx_queue_len      = 0;
+	dev->flags             = IFF_NOARP;
+
+	/* set flags according to driver capabilities */
+	if (echo)
+		dev->flags |= IFF_ECHO;
+
+	dev->open              = vcan_open;
+	dev->stop              = vcan_stop;
+	dev->hard_start_xmit   = vcan_tx;
+	dev->destructor        = free_netdev;
+}
+
+static struct rtnl_link_ops vcan_link_ops __read_mostly = {
+       .kind           = "vcan",
+       .setup          = vcan_setup,
+};
+
+static __init int vcan_init_module(void)
+{
+	printk(banner);
+
+	if (echo)
+		printk(KERN_INFO "vcan: enabled echo on driver level.\n");
+
+	return rtnl_link_register(&vcan_link_ops);
+}
+
+static __exit void vcan_cleanup_module(void)
+{
+	rtnl_link_unregister(&vcan_link_ops);
+}
+
+module_init(vcan_init_module);
+module_exit(vcan_cleanup_module);
Index: net-2.6.24/net/can/Kconfig
===================================================================
--- net-2.6.24.orig/net/can/Kconfig	2007-10-02 12:03:28.000000000 +0200
+++ net-2.6.24/net/can/Kconfig	2007-10-02 12:03:30.000000000 +0200
@@ -47,3 +47,6 @@
 	  Say Y here if you want the CAN core to produce a bunch of debug
 	  messages to the system log.  Select this if you are having a
 	  problem with CAN support and want to see more of what is going on.
+
+
+source "drivers/net/can/Kconfig"

--

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Arnaldo Carvalho de Melo]

Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
> This patch adds the virtual CAN bus (vcan) network driver.
> The vcan device is just a loopback device for CAN frames, no
> real CAN hardware is involved.
> 
> Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
> Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>
> 
> ---
>  drivers/net/Makefile     |    1 
>  drivers/net/can/Kconfig  |   25 +++++
>  drivers/net/can/Makefile |    5 +
>  drivers/net/can/vcan.c   |  207 +++++++++++++++++++++++++++++++++++++++++++++++
>  net/can/Kconfig          |    3 
>  5 files changed, 241 insertions(+)
> 
> Index: net-2.6.24/drivers/net/Makefile
> ===================================================================
> --- net-2.6.24.orig/drivers/net/Makefile	2007-09-20 23:46:01.000000000 +0200
> +++ net-2.6.24/drivers/net/Makefile	2007-10-02 12:03:30.000000000 +0200
> @@ -12,6 +12,7 @@
>  obj-$(CONFIG_CHELSIO_T1) += chelsio/
>  obj-$(CONFIG_CHELSIO_T3) += cxgb3/
>  obj-$(CONFIG_EHEA) += ehea/
> +obj-$(CONFIG_CAN) += can/
>  obj-$(CONFIG_BONDING) += bonding/
>  obj-$(CONFIG_ATL1) += atl1/
>  obj-$(CONFIG_GIANFAR) += gianfar_driver.o
> Index: net-2.6.24/drivers/net/can/Kconfig
> ===================================================================
> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ net-2.6.24/drivers/net/can/Kconfig	2007-10-02 12:03:30.000000000 +0200
> @@ -0,0 +1,25 @@
> +menu "CAN Device Drivers"
> +	depends on CAN
> +
> +config CAN_VCAN
> +	tristate "Virtual Local CAN Interface (vcan)"
> + 	depends on CAN
> +	default N
> + 	---help---
> +	  Similar to the network loopback devices, vcan offers a
> +	  virtual local CAN interface.
> +
> +	  This driver can also be built as a module.  If so, the module
> +	  will be called vcan.
> +
> +config CAN_DEBUG_DEVICES
> +	bool "CAN devices debugging messages"
> +	depends on CAN
> +	default N
> +	---help---
> +	  Say Y here if you want the CAN device drivers to produce a bunch of
> +	  debug messages to the system log.  Select this if you are having
> +	  a problem with CAN support and want to see more of what is going
> +	  on.
> +
> +endmenu
> Index: net-2.6.24/drivers/net/can/Makefile
> ===================================================================
> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ net-2.6.24/drivers/net/can/Makefile	2007-10-02 12:03:30.000000000 +0200
> @@ -0,0 +1,5 @@
> +#
> +#  Makefile for the Linux Controller Area Network drivers.
> +#
> +
> +obj-$(CONFIG_CAN_VCAN)		+= vcan.o
> Index: net-2.6.24/drivers/net/can/vcan.c
> ===================================================================
> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ net-2.6.24/drivers/net/can/vcan.c	2007-10-02 12:03:30.000000000 +0200
> @@ -0,0 +1,207 @@
> +/*
> + * vcan.c - Virtual CAN interface
> + *
> + * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *    notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *    notice, this list of conditions and the following disclaimer in the
> + *    documentation and/or other materials provided with the distribution.
> + * 3. Neither the name of Volkswagen nor the names of its contributors
> + *    may be used to endorse or promote products derived from this software
> + *    without specific prior written permission.
> + *
> + * Alternatively, provided that this notice is retained in full, this
> + * software may be distributed under the terms of the GNU General
> + * Public License ("GPL") version 2, in which case the provisions of the
> + * GPL apply INSTEAD OF those given above.
> + *
> + * The provided data structures and external interfaces from this code
> + * are not restricted to be used by modules with a GPL compatible license.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> + * DAMAGE.
> + *
> + * Send feedback to <socketcan-users@lists.berlios.de>
> + *
> + */
> +
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/netdevice.h>
> +#include <linux/if_arp.h>
> +#include <linux/if_ether.h>
> +#include <linux/can.h>
> +#include <net/rtnetlink.h>
> +
> +static __initdata const char banner[] =
> +	KERN_INFO "vcan: Virtual CAN interface driver\n";
> +
> +MODULE_DESCRIPTION("virtual CAN interface");
> +MODULE_LICENSE("Dual BSD/GPL");
> +MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
> +
> +#ifdef CONFIG_CAN_DEBUG_DEVICES
> +static int debug;
> +module_param(debug, int, S_IRUGO);
> +#endif

Can debug be a boolean? Like its counterpart on DCCP:

net/dccp/proto.c:

module_param(dccp_debug, bool, 0444);

Where we also use a namespace prefix, for those of us who use ctags or
cscope.


> +
> +/* To be moved to linux/can/dev.h */

Is this comment still valid? If so can this move happen now? If not I
think it would be better to stick a "FIXME: " just before it, no?

> +#ifdef CONFIG_CAN_DEBUG_DEVICES
> +#define DBG(fmt, args...)  (debug & 1 ? \
> +				printk(KERN_DEBUG "vcan %s: " fmt, \
> +				__func__, ##args) : 0)
> +#else
> +#define DBG(fmt, args...)
> +#endif
> +
> +
> +/*
> + * CAN test feature:
> + * Enable the echo on driver level for testing the CAN core echo modes.
> + * See Documentation/networking/can.txt for details.
> + */
> +
> +static int echo; /* echo testing. Default: 0 (Off) */
> +module_param(echo, int, S_IRUGO);
> +MODULE_PARM_DESC(echo, "Echo sent frames (for testing). Default: 0 (Off)");

echo also seems to be a boolean

> +
> +
> +static int vcan_open(struct net_device *dev)
> +{
> +	DBG("%s: interface up\n", dev->name);
> +
> +	netif_start_queue(dev);
> +	return 0;
> +}
> +
> +static int vcan_stop(struct net_device *dev)
> +{
> +	DBG("%s: interface down\n", dev->name);
> +
> +	netif_stop_queue(dev);
> +	return 0;
> +}

Thinking out loud: I guess these days we can try to reduce the clutter
on the source code for things like "hey, I entered function foo" using
simple systemtap scripts, that could even be shipped with the kernel
sources. Not something pressing right now, just a suggestion.

> +static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
> +{
> +	struct net_device_stats *stats = &dev->stats;
> +
> +	stats->rx_packets++;
> +	stats->rx_bytes += skb->len;
> +
> +	skb->protocol  = htons(ETH_P_CAN);
> +	skb->pkt_type  = PACKET_BROADCAST;
> +	skb->dev       = dev;
> +	skb->ip_summed = CHECKSUM_UNNECESSARY;
> +
> +	DBG("received skbuff on interface %d\n", dev->ifindex);
> +
> +	netif_rx(skb);
> +}
> +
> +static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
> +{
> +	struct net_device_stats *stats = &dev->stats;
> +	int loop;
> +
> +	DBG("sending skbuff on interface %s\n", dev->name);
> +
> +	stats->tx_packets++;
> +	stats->tx_bytes += skb->len;
> +
> +	/* set flag whether this packet has to be looped back */
> +	loop = skb->pkt_type == PACKET_LOOPBACK;
> +
> +	if (!echo) {
> +		/* no echo handling available inside this driver */
> +
> +		if (loop) {
> +			/*
> +			 * only count the packets here, because the
> +			 * CAN core already did the echo for us
> +			 */
> +			stats->rx_packets++;
> +			stats->rx_bytes += skb->len;
> +		}
> +		kfree_skb(skb);
> +		return 0;
> +	}
> +
> +	/* perform standard echo handling for CAN network interfaces */
> +
> +	if (loop) {
> +		struct sock *srcsk = skb->sk;
> +
> +		skb = skb_share_check(skb, GFP_ATOMIC);
> +		if (!skb)
> +			return 0;
> +
> +		/* receive with packet counting */
> +		skb->sk = srcsk;
> +		vcan_rx(skb, dev);
> +	} else {
> +		/* no looped packets => no counting */
> +		kfree_skb(skb);
> +	}
> +	return 0;
> +}
> +
> +static void vcan_setup(struct net_device *dev)
> +{
> +	DBG("dev %s\n", dev->name);
> +
> +	dev->type              = ARPHRD_CAN;
> +	dev->mtu               = sizeof(struct can_frame);
> +	dev->hard_header_len   = 0;
> +	dev->addr_len          = 0;
> +	dev->tx_queue_len      = 0;
> +	dev->flags             = IFF_NOARP;
> +
> +	/* set flags according to driver capabilities */
> +	if (echo)
> +		dev->flags |= IFF_ECHO;
> +
> +	dev->open              = vcan_open;
> +	dev->stop              = vcan_stop;
> +	dev->hard_start_xmit   = vcan_tx;
> +	dev->destructor        = free_netdev;
> +}
> +
> +static struct rtnl_link_ops vcan_link_ops __read_mostly = {
> +       .kind           = "vcan",
> +       .setup          = vcan_setup,
> +};
> +
> +static __init int vcan_init_module(void)
> +{
> +	printk(banner);
> +
> +	if (echo)
> +		printk(KERN_INFO "vcan: enabled echo on driver level.\n");
> +
> +	return rtnl_link_register(&vcan_link_ops);
> +}
> +
> +static __exit void vcan_cleanup_module(void)
> +{
> +	rtnl_link_unregister(&vcan_link_ops);
> +}
> +
> +module_init(vcan_init_module);
> +module_exit(vcan_cleanup_module);
> Index: net-2.6.24/net/can/Kconfig
> ===================================================================
> --- net-2.6.24.orig/net/can/Kconfig	2007-10-02 12:03:28.000000000 +0200
> +++ net-2.6.24/net/can/Kconfig	2007-10-02 12:03:30.000000000 +0200
> @@ -47,3 +47,6 @@
>  	  Say Y here if you want the CAN core to produce a bunch of debug
>  	  messages to the system log.  Select this if you are having a
>  	  problem with CAN support and want to see more of what is going on.
> +
> +
> +source "drivers/net/can/Kconfig"
> 
> --

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Arnaldo Carvalho de Melo wrote:
> Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
>   
>
>> +
>> +/* To be moved to linux/can/dev.h */
>>     
>
> Is this comment still valid? If so can this move happen now? If not I
> think it would be better to stick a "FIXME: " just before it, no?
>
>   

Bringing all the current available CAN network device drivers into 
Kernel style qualitiy is a TODO for the time after the PF_CAN core is 
mainlined.

When more than this single vcan CAN netdev driver is part of the Kernel 
it makes sense to put several things (like the common configuration 
interface and commonly used library funtions for CAN drivers) into 
linux/can/dev.h. And at that time this currently local DEBUG definition 
should go there togehther with the other stuff.

Please think of all the comments, if we created a single dev.h file with 
a single DEBUG definition used by a single vcan.c file ;-)

Oliver

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Arnaldo Carvalho de Melo]

Em Tue, Oct 02, 2007 at 05:07:40PM +0200, Oliver Hartkopp escreveu:
> Arnaldo Carvalho de Melo wrote:
>> Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
>>   
>>> +
>>> +/* To be moved to linux/can/dev.h */
>>>     
>>
>> Is this comment still valid? If so can this move happen now? If not I
>> think it would be better to stick a "FIXME: " just before it, no?
>>
>>   
>
> Bringing all the current available CAN network device drivers into Kernel 
> style qualitiy is a TODO for the time after the PF_CAN core is mainlined.
>
> When more than this single vcan CAN netdev driver is part of the Kernel it 
> makes sense to put several things (like the common configuration interface 
> and commonly used library funtions for CAN drivers) into linux/can/dev.h. 
> And at that time this currently local DEBUG definition should go there 
> togehther with the other stuff.
>
> Please think of all the comments, if we created a single dev.h file with a 
> single DEBUG definition used by a single vcan.c file ;-)

Don't get to defensive. You know a lot more than me about the code you
worked for that many years. Its just that it looked suspicious for a
casual reviewer. :-)

- Arnaldo

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Arnaldo Carvalho de Melo wrote:
> Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
>   
>> +
>> +#ifdef CONFIG_CAN_DEBUG_DEVICES
>> +static int debug;
>> +module_param(debug, int, S_IRUGO);
>> +#endif
>>     
>
> Can debug be a boolean? Like its counterpart on DCCP:
>
> net/dccp/proto.c:
>
> module_param(dccp_debug, bool, 0444);
>   

'debug' should remain an integer to be able to specifiy debug-levels or 
bit-fields for different Debug outputs.

> Where we also use a namespace prefix, for those of us who use ctags or
> cscope.
>   

Even if i don't have any general objections to rename this 'debug' to 
'vcan_debug', it looks like an 'overnamed' module parameter for me. Is 
this a genereal naming scheme recommendation for debug module_params?

>
>> +/*
>> + * CAN test feature:
>> + * Enable the echo on driver level for testing the CAN core echo modes.
>> + * See Documentation/networking/can.txt for details.
>> + */
>> +
>> +static int echo; /* echo testing. Default: 0 (Off) */
>> +module_param(echo, int, S_IRUGO);
>> +MODULE_PARM_DESC(echo, "Echo sent frames (for testing). Default: 0 (Off)");
>>     
>
> echo also seems to be a boolean
>
>   

Yes. This is definitely a boolean candidate. We'll change that.

Thanks,
Oliver

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Arnaldo Carvalho de Melo]

Em Tue, Oct 02, 2007 at 11:02:53PM +0200, Oliver Hartkopp escreveu:
> Arnaldo Carvalho de Melo wrote:
>> Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
>>   
>>> +
>>> +#ifdef CONFIG_CAN_DEBUG_DEVICES
>>> +static int debug;
>>> +module_param(debug, int, S_IRUGO);
>>> +#endif
>>>     
>>
>> Can debug be a boolean? Like its counterpart on DCCP:
>>
>> net/dccp/proto.c:
>>
>> module_param(dccp_debug, bool, 0444);
>>   
>
> 'debug' should remain an integer to be able to specifiy debug-levels or 
> bit-fields for different Debug outputs.
>
>> Where we also use a namespace prefix, for those of us who use ctags or
>> cscope.
>>   
>
> Even if i don't have any general objections to rename this 'debug' to 
> 'vcan_debug', it looks like an 'overnamed' module parameter for me. Is this 
> a genereal naming scheme recommendation for debug module_params?

[acme@mica linux-2.6.23-rc9-rt1]$ find . -name "*.c" | xargs grep
'module_param(.\+debug,' | wc -l
112
[acme@mica linux-2.6.23-rc9-rt1]$ find . -name "*.c" | xargs grep
'module_param(debug,' | wc -l
233
[acme@mica linux-2.6.23-rc9-rt1]$

I think that helping ctags to find the definition for the debug variable
to see, for instance, if it is a bitmask or a boolean without having to
chose from tons of 'debug' variables is a good thing.

- Arnaldo

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[David Miller]

From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Date: Tue, 2 Oct 2007 18:43:25 -0300

> I think that helping ctags to find the definition for the debug variable
> to see, for instance, if it is a bitmask or a boolean without having to
> chose from tons of 'debug' variables is a good thing.

I completely agree.

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

David Miller wrote:
> From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
> Date: Tue, 2 Oct 2007 18:43:25 -0300
>
>   
>> I think that helping ctags to find the definition for the debug variable
>> to see, for instance, if it is a bitmask or a boolean without having to
>> chose from tons of 'debug' variables is a good thing.
>>     
>
> I completely agree.
>   

OK. No problem if it's helpful. We'll change debug to vcan_debug.

Thanks.

Oliver

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Stephen Hemminger]

On Tue, 02 Oct 2007 23:02:53 +0200
Oliver Hartkopp <oliver@hartkopp.net> wrote:

> Arnaldo Carvalho de Melo wrote:
> > Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
> >   
> >> +
> >> +#ifdef CONFIG_CAN_DEBUG_DEVICES
> >> +static int debug;
> >> +module_param(debug, int, S_IRUGO);
> >> +#endif
> >>     
> >
> > Can debug be a boolean? Like its counterpart on DCCP:
> >
> > net/dccp/proto.c:
> >
> > module_param(dccp_debug, bool, 0444);
> >   
> 
> 'debug' should remain an integer to be able to specifiy debug-levels or 
> bit-fields for different Debug outputs.
> 
> > Where we also use a namespace prefix, for those of us who use ctags or
> > cscope.
> >   
> 
> Even if i don't have any general objections to rename this 'debug' to 
> 'vcan_debug', it looks like an 'overnamed' module parameter for me. Is 
> this a genereal naming scheme recommendation for debug module_params?
> 

Please consider using netif_msg_xxx() and module parameter to set
default message level, like other real network drivers already do.

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[David Miller]

From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Tue, 2 Oct 2007 14:52:36 -0700

> Please consider using netif_msg_xxx() and module parameter to set
> default message level, like other real network drivers already do.

I keep seeing this recommendation, but the two supposedly most mature
and actively used drivers in the tree, tg3 and e1000 and e1000e, all
do not use this scheme.

In fact there are tons of drivers that even hook up the ethtool
msg_level setting function and never even use the value.

If people aren't using netif_msg_xxx() and the ethtool msg_level
facilities properly, it's because there is a severe dearth of good
example drivers to learn about it from.

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

David Miller wrote:
> From: Stephen Hemminger <shemminger@linux-foundation.org>
> Date: Tue, 2 Oct 2007 14:52:36 -0700
>
>   
>> Please consider using netif_msg_xxx() and module parameter to set
>> default message level, like other real network drivers already do.
>>     
>
> I keep seeing this recommendation, but the two supposedly most mature
> and actively used drivers in the tree, tg3 and e1000 and e1000e, all
> do not use this scheme.
>
> In fact there are tons of drivers that even hook up the ethtool
> msg_level setting function and never even use the value.
>
> If people aren't using netif_msg_xxx() and the ethtool msg_level
> facilities properly, it's because there is a severe dearth of good
> example drivers to learn about it from.
>   

The currently available CAN netdevice drivers do not have a common debug 
concept neither any runtime control mechanism for this debugging. So 
netif_msg_xxx() is definitely worth to look at instead of creating any 
new stuff in this direction, before posting any 'real' CAN network 
driver here.

Thanks very much for that hint!

Oliver

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

Arnaldo Carvalho de Melo <acme@ghostprotocols.net> writes:

> > +#ifdef CONFIG_CAN_DEBUG_DEVICES
> > +static int debug;
> > +module_param(debug, int, S_IRUGO);
> > +#endif
> 
> Can debug be a boolean? Like its counterpart on DCCP:

debug used to a bit mask, like it still is in core.h.  You can see
this in the test

        debug & 1 ? ... : ...

below.  Only the test for bit 0 is left, so we could change it to bool.

> net/dccp/proto.c:
> 
> module_param(dccp_debug, bool, 0444);
> 
> Where we also use a namespace prefix, for those of us who use ctags or
> cscope.

I think ctags should be able to handle multiple identical static
symbols.  Isn't it?  I find it somewhat clumsy to write

        modprobe vcan vcan_debug=1

I think it would be nice to change the module_param() macro so that
you can name the module argument and the corresponding variable
independently, like

        module_param(can_debug, "debug", bool, 0444);

OK, forget that last paragraph.  I've looked at the definition of
module_param() and have seen that we have module_param_named().  I
think we should use that.

> > +
> > +/* To be moved to linux/can/dev.h */
> 
> Is this comment still valid? If so can this move happen now? If not I
> think it would be better to stick a "FIXME: " just before it, no?

OK.

> > +static int echo; /* echo testing. Default: 0 (Off) */
> > +module_param(echo, int, S_IRUGO);
> > +MODULE_PARM_DESC(echo, "Echo sent frames (for testing). Default: 0 (Off)");
> 
> echo also seems to be a boolean

ACK.

> > +static int vcan_open(struct net_device *dev)
> > +{
> > +	DBG("%s: interface up\n", dev->name);
> > +
> > +	netif_start_queue(dev);
> > +	return 0;
> > +}
> > +
> > +static int vcan_stop(struct net_device *dev)
> > +{
> > +	DBG("%s: interface down\n", dev->name);
> > +
> > +	netif_stop_queue(dev);
> > +	return 0;
> > +}
> 
> Thinking out loud: I guess these days we can try to reduce the clutter
> on the source code for things like "hey, I entered function foo" using
> simple systemtap scripts, that could even be shipped with the kernel
> sources. Not something pressing right now, just a suggestion.

I've never heard of systemtap before.  I've ust looked at its overview
web page which sounds promising.  I think I'll check it out when time
permits...


urs

[PATCH 0/7] CAN: Add new PF_CAN protocol family, try #7

[Urs Thuermann]

Hello Dave, hello Patrick,

this is the seventh post of the patch series that adds the PF_CAN
protocol family for the Controller Area Network.

Since our last post we have changed the following:

* Changes suggested by Patrick:
  - protect proto_tab[] by a lock.
  - add _rcu to some hlist traversals.
  - use printk_ratelimit() for module autoload failures.
  - make can_proto_unregister() and can_rx_unregister() return void.
  - use return value of can_proto_register() and can_rx_register()
    (this also removed a flaw in behavior of raw_bind() and raw_setsockopt()
     in case of failure to can_rx_register() their filters).
  - call kzalloc() with GFP_KERNEL in case NETDEV_REGISTER.
  - use round_jiffies() to calculate expiration times.
  - make some variables static and/or __read_mostly.
  - in can_create() check for net namespace before auto loading modules.
  - add build time check for struct sizes.
  - use skb_share_chack() in vcan.
  - fixed some comments.
* Typos in documentation as pointed out by Randy Dunlap and Bill Fink.

The changes in try #6 were:

* Update code to work with namespaces in net-2.6.24.
* Remove SET_MODULE_OWNER() from vcan.

The changes in try #5 were:

* Remove slab destructor from calls to kmem_cache_alloc().
* Add comments about types defined in can.h.
* Update comment on vcan loopback module parameter.
* Fix typo in documentation.

The changes in try #4 were:

* Change vcan network driver to use the new RTNL API, as suggested by
  Patrick.
* Revert our change to use skb->iif instead of skb->cb.  After
  discussion with Patrick and Jamal it turned out, our first
  implementation was correct.
* Use skb_tail_pointer() instead of skb->tail directly.
* Coding style changes to satisfy linux/scripts/checkpatch.pl.
* Minor changes for 64-bit-cleanliness.
* Minor cleanup of #include's

The changes in try #3 were:

* Use sbk->sk and skb->pkt_type instead of skb->cb to pass loopback
  flags and originating socket down to the driver and back to the
  receiving socket.  Thanks to Patrick McHardy for pointing out our
  wrong use of sbk->cb.
* Use skb->iif instead of skb->cb to pass receiving interface from
  raw_rcv() and bcm_rcv() up to raw_recvmsg() and bcm_recvmsg().
* Set skb->protocol when sending CAN frames to netdevices.
* Removed struct raw_opt and struct bcm_opt and integrated these
  directly into struct raw_sock and bcm_sock resp., like most other
  proto implementations do.
* We have found and fixed race conditions between raw_bind(),
  raw_{set,get}sockopt() and raw_notifier().  This resulted in
  - complete removal of our own notifier list infrastructure in
    af_can.c.  raw.c and bcm.c now use normal netdevice notifiers.
  - removal of ro->lock spinlock.  We use lock_sock(sk) now.
  - changed deletion of dev_rcv_lists, which are now marked for
    deletion in the netdevice notifier in af_can.c and are actually
    deleted when all entries have been deleted using can_rx_unregister().
* Follow changes in 2.6.22 (e.g. ktime_t timestamps in skb).
* Removed obsolete code from vcan.c, as pointed out by Stephen Hemminger.

The changes in try #2 were:

* reduced RCU callback overhead when deleting receiver lists (thx to
  feedback from Paul E. McKenney).
* eliminated some code duplication in net/can/proc.c.
* renamed slock-29 and sk_lock-29 to slock-AF_CAN and sk_lock-AF_CAN in
  net/core/sock.c
* added entry for can.txt in Documentation/networking/00-INDEX
* added error frame definitions in include/linux/can/error.h, which are to
  be used by CAN network drivers.


This patch series applies against net-2.6.24 and is derived from Subversion
revision r484 of http://svn.berlios.de/svnroot/repos/socketcan.
It can be found in the directory
http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/<version>.

Thanks very much for your work!

Best regards,

Urs Thuermann
Oliver Hartkopp


P.S. Greetings from some BSD and Linux users here at the LUG meeting in
     Braunschweig :-)
--

[PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

[-- Attachment #1: 05-can-vcan-driver.diff --]
[-- Type: text/plain, Size: 9153 bytes --]

This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 drivers/net/Makefile     |    1 
 drivers/net/can/Kconfig  |   25 +++++
 drivers/net/can/Makefile |    5 +
 drivers/net/can/vcan.c   |  208 +++++++++++++++++++++++++++++++++++++++++++++++
 net/can/Kconfig          |    3 
 5 files changed, 242 insertions(+)

Index: net-2.6.24/drivers/net/Makefile
===================================================================
--- net-2.6.24.orig/drivers/net/Makefile	2007-09-20 18:48:21.000000000 +0200
+++ net-2.6.24/drivers/net/Makefile	2007-09-20 18:49:00.000000000 +0200
@@ -10,6 +10,7 @@
 obj-$(CONFIG_CHELSIO_T1) += chelsio/
 obj-$(CONFIG_CHELSIO_T3) += cxgb3/
 obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
 obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_ATL1) += atl1/
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: net-2.6.24/drivers/net/can/Kconfig
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/drivers/net/can/Kconfig	2007-09-20 18:49:00.000000000 +0200
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+	depends on CAN
+
+config CAN_VCAN
+	tristate "Virtual Local CAN Interface (vcan)"
+ 	depends on CAN
+	default N
+ 	---help---
+	  Similar to the network loopback devices, vcan offers a
+	  virtual local CAN interface.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called vcan.
+
+config CAN_DEBUG_DEVICES
+	bool "CAN devices debugging messages"
+	depends on CAN
+	default N
+	---help---
+	  Say Y here if you want the CAN device drivers to produce a bunch of
+	  debug messages to the system log.  Select this if you are having
+	  a problem with CAN support and want to see more of what is going
+	  on.
+
+endmenu
Index: net-2.6.24/drivers/net/can/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/drivers/net/can/Makefile	2007-09-20 18:49:00.000000000 +0200
@@ -0,0 +1,5 @@
+#
+#  Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN)		+= vcan.o
Index: net-2.6.24/drivers/net/can/vcan.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/drivers/net/can/vcan.c	2007-09-20 18:49:00.000000000 +0200
@@ -0,0 +1,208 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions, the following disclaimer and
+ *    the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/if_arp.h>
+#include <linux/if_ether.h>
+#include <linux/can.h>
+#include <net/rtnetlink.h>
+
+static __initdata const char banner[] =
+	KERN_INFO "vcan: Virtual CAN interface driver\n";
+
+MODULE_DESCRIPTION("virtual CAN interface");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
+
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+static int debug;
+module_param(debug, int, S_IRUGO);
+#endif
+
+/* To be moved to linux/can/dev.h */
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+#define DBG(args...)       (debug & 1 ? \
+			       (printk(KERN_DEBUG "vcan %s: ", __func__), \
+				printk(args)) : 0)
+#else
+#define DBG(args...)
+#endif
+
+
+/*
+ * CAN test feature:
+ * Enable the loopback on driver level for testing the CAN core loopback modes.
+ * See Documentation/networking/can.txt for details.
+ */
+
+static int loopback; /* loopback testing. Default: 0 (Off) */
+module_param(loopback, int, S_IRUGO);
+MODULE_PARM_DESC(loopback, "Loop back frames (for testing). Default: 0 (Off)");
+
+
+static int vcan_open(struct net_device *dev)
+{
+	DBG("%s: interface up\n", dev->name);
+
+	netif_start_queue(dev);
+	return 0;
+}
+
+static int vcan_stop(struct net_device *dev)
+{
+	DBG("%s: interface down\n", dev->name);
+
+	netif_stop_queue(dev);
+	return 0;
+}
+
+static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+
+	stats->rx_packets++;
+	stats->rx_bytes += skb->len;
+
+	skb->protocol  = htons(ETH_P_CAN);
+	skb->pkt_type  = PACKET_BROADCAST;
+	skb->dev       = dev;
+	skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	DBG("received skbuff on interface %d\n", dev->ifindex);
+
+	netif_rx(skb);
+}
+
+static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+	int loop;
+
+	DBG("sending skbuff on interface %s\n", dev->name);
+
+	stats->tx_packets++;
+	stats->tx_bytes += skb->len;
+
+	/* set flag whether this packet has to be looped back */
+	loop = skb->pkt_type == PACKET_LOOPBACK;
+
+	if (!loopback) {
+		/* no loopback handling available inside this driver */
+
+		if (loop) {
+			/*
+			 * only count the packets here, because the
+			 * CAN core already did the loopback for us
+			 */
+			stats->rx_packets++;
+			stats->rx_bytes += skb->len;
+		}
+		kfree_skb(skb);
+		return 0;
+	}
+
+	/* perform standard loopback handling for CAN network interfaces */
+
+	if (loop) {
+		struct sock *srcsk = skb->sk;
+
+		skb = skb_share_check(skb, GFP_ATOMIC);
+		if (!skb)
+			return 0;
+
+		/* receive with packet counting */
+		skb->sk = srcsk;
+		vcan_rx(skb, dev);
+	} else {
+		/* no looped packets => no counting */
+		kfree_skb(skb);
+	}
+	return 0;
+}
+
+static void vcan_setup(struct net_device *dev)
+{
+	DBG("dev %s\n", dev->name);
+
+	dev->type              = ARPHRD_CAN;
+	dev->mtu               = sizeof(struct can_frame);
+	dev->hard_header_len   = 0;
+	dev->addr_len          = 0;
+	dev->tx_queue_len      = 0;
+	dev->flags             = IFF_NOARP;
+
+	/* set flags according to driver capabilities */
+	if (loopback)
+		dev->flags |= IFF_LOOPBACK;
+
+	dev->open              = vcan_open;
+	dev->stop              = vcan_stop;
+	dev->hard_start_xmit   = vcan_tx;
+	dev->destructor        = free_netdev;
+}
+
+static struct rtnl_link_ops vcan_link_ops __read_mostly = {
+       .kind           = "vcan",
+       .setup          = vcan_setup,
+};
+
+static __init int vcan_init_module(void)
+{
+	printk(banner);
+
+	if (loopback)
+		printk(KERN_INFO "vcan: enabled loopback on driver level.\n");
+
+	return rtnl_link_register(&vcan_link_ops);
+}
+
+static __exit void vcan_cleanup_module(void)
+{
+	rtnl_link_unregister(&vcan_link_ops);
+}
+
+module_init(vcan_init_module);
+module_exit(vcan_cleanup_module);
Index: net-2.6.24/net/can/Kconfig
===================================================================
--- net-2.6.24.orig/net/can/Kconfig	2007-09-20 18:48:59.000000000 +0200
+++ net-2.6.24/net/can/Kconfig	2007-09-20 18:49:00.000000000 +0200
@@ -77,3 +77,6 @@
 	  Say Y here if you want the CAN core to produce a bunch of debug
 	  messages to the system log.  Select this if you are having a
 	  problem with CAN support and want to see more of what is going on.
+
+
+source "drivers/net/can/Kconfig"

--

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Eric W. Biederman]

Urs Thuermann <urs@isnogud.escape.de> writes:

> This patch adds the virtual CAN bus (vcan) network driver.
> The vcan device is just a loopback device for CAN frames, no
> real CAN hardware is involved.

I'm trying to wrap my head around the CAN use of IFF_LOOPBACK.

>  6.2 loopback
>
>  As described in chapter 3.2 the CAN network device driver should
>  support a local loopback functionality. In this case the driver flag
>  IFF_LOOPBACK has to be set to cause the PF_CAN core to not perform the
>  loopback as fallback solution:
>
>    dev->flags = (IFF_NOARP | IFF_LOOPBACK);
>

Currently IFF_LOOPBACK set in dev->flags means we are dealing
with drivers/net/loopback.c. 

In other networking layers loopback functionality (i.e. for broadcast)
is never expected to be provided by the drivers and is instead 
always provided by the networking layer.  Keeping the drivers
simpler.  Further you already have this functionality in the
generic CAN layer for doing loopback without driver support.

So at a first glance the CAN usage of IFF_LOOPBACK looks completely
broken, and likely to confuse other networking layers if they see
a CAN device.  Say if someone attempts to run IP over CAN or
something like that.

Do you think you can remove this incompatible usage of IFF_LOOPBACK
from the can code?

If I have read your documentation properly the only reason you are
doing this is so that the timing of frames to cansniffer more
accurately reflects when the frame hits the wire.  If CAN runs over a
very slow medium I guess I can see where that can be a concern.  But
the usage of IFF_LOOPBACK to do this still feels fairly hackish
to me. 

Eric

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Eric W. Biederman]

I guess in particular IFF_LOOPBACK means that all packets from
a device will come right back to the current machine, and go
nowhere else.

That usage sounds completely different then the CAN usage which
appears to mean.  Broadcast packets will be returned to this machine
as well as being sent out onto the wire.

Eric

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[David Miller]

From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 27 Sep 2007 10:16:37 -0600

> 
> I guess in particular IFF_LOOPBACK means that all packets from
> a device will come right back to the current machine, and go
> nowhere else.
> 
> That usage sounds completely different then the CAN usage which
> appears to mean.  Broadcast packets will be returned to this machine
> as well as being sent out onto the wire.

It's bogus and it should be removed from the CAN code, they
can add some other attribute to achieve their goals.

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Eric W. Biederman wrote:
>
> Currently IFF_LOOPBACK set in dev->flags means we are dealing
> with drivers/net/loopback.c. 
>   

This is a very general view, don't you think? The one is an interface
flag and the other one is an interface itself. This looks like a risky
mixture, when there is no clean separation.

> In other networking layers loopback functionality (i.e. for broadcast)
> is never expected to be provided by the drivers and is instead 
> always provided by the networking layer.  Keeping the drivers
> simpler.  Further you already have this functionality in the
> generic CAN layer for doing loopback without driver support.
>   

ACK & Yes.

> So at a first glance the CAN usage of IFF_LOOPBACK looks completely
> broken, and likely to confuse other networking layers if they see
> a CAN device.  Say if someone attempts to run IP over CAN or
> something like that.
>   

The CAN protocol family is some kind of a closed ecosystem with a
complete different addressing scheme that uses the bare networking
functionality of the Linux Kernel as well as DECNET or ARCNET. You would
never been able to run the IP-stack on a CAN netdev (ARPHDR_CAN,
ETH_P_CAN) due to several technical differences in addressing, etc.

> Do you think you can remove this incompatible usage of IFF_LOOPBACK
> from the can code?
>   

Yes. We might pick another name for it (see below).

> If I have read your documentation properly the only reason you are
> doing this is so that the timing of frames to cansniffer more
> accurately reflects when the frame hits the wire.  If CAN runs over a
> very slow medium I guess I can see where that can be a concern.

It's not really a (more accurate) timing problem but a media access
issue that occurs on the CAN bus itself:

The CAN bus is in opposite to an Ethernet a CSMA/CA (collision
*avoidance*) medium with an arbitration that's controlled with the so
called CAN-Identifier. The lower the CAN-Id value the higher is it's
priority. E.g. a CAN frame with an CAN-Id of 0x100 can squeeze out a CAN
frame with a CAN-Id of 0x400 on the bus, so that the CAN frame with the
CAN-Id of 0x400 is to be sent again (_automatically_ by the CAN
controller chip).

An example:
You want to send CAN-Id 0x700 on the bus, and put all the data into your
local CAN controller chip and start the transmission. When your local
controller wants to send it's frame it looses it's arbitration due to a
reception of a CAN-Id 0x100 and generates a RX-interrupt for this
received frame. After that your local controller tries to resend his
frame but it looses it's arbitration again due to a reception of a
CAN-Id 0x400 and generates a RX-interrupt for this received frame.
Finally your local controller tries to resend his frame, has success,
and generates a TX-interrupt for his successfully sent frame.

When you use the network layer loopback functionality the other
applications on your local host would see CAN-Id 0x700, CAN-Id 0x100,
CAN-Id 0x400. When you use the loopback on driver level you would see
the _correct_ message order CAN-Id 0x100, CAN-Id 0x400, CAN-Id 0x700.

So it's not an issue of having better timings but to reproduce the
*correct message order* from the CAN bus. One year ago this problem has
originally been pointed out by Michael Schulze from the University of
Magdeburg as having a correct message order created by the CSMA/CA
treatment is a vital requirement for CAN bus users. As you might see now
the CAN netdriver has to offer additional functionalities due to the
CSMA/CA treatment in opposite to the 'standard' CSMA/CD behaviour you
know from Ethernet netdrivers. And this arbitration information of the
CAN controller is only available on driver level. It is therefore no
question IF the CAN netdriver supports the CSMA/CA treatment but HOW to
provide an interface for this functionality on a basis of a standard
netdriver (which simply only sends and receives frames).

As the CAN netdrivers (as described above) are only available and used
by the PF_CAN core, the use of IFF_LOOPBACK looked like reasonable
solution to distinguish whether the CAN netdriver is capable to do the
loopback (e.g. due to the ability of the controller to generate
TX-interrupts) or not. The usage of IFF_LOOPBACK in CAN netdrivers
didn't affect or confuse the rest of the Linux networking system up to
now. Btw. if you state that IFF_LOOPBACK means for a netdriver, that
"all packets from a device will come right back to the current machine,
and go nowhere else.", we should think about a new IFF_-flag here.

I don't have any concerns creating a new IFF_-flag for this "loopback
approved by CSMA/CA media access" i just have no idea for a really good
name for it. But maybe the use of IFF_LOOPBACK for CAN netdrivers
(ARPHRD_CAN) is also ok for you now?!?

Oliver

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Eric W. Biederman]

Oliver Hartkopp <oliver@hartkopp.net> writes:

> Eric W. Biederman wrote:
>>
>> Currently IFF_LOOPBACK set in dev->flags means we are dealing
>> with drivers/net/loopback.c. 
>>   
>
> This is a very general view, don't you think? The one is an interface
> flag and the other one is an interface itself. This looks like a risky
> mixture, when there is no clean separation.

The better definition followed that IFF_LOOPBACK means all packets
will loopback.  Currently we only have one such device in the tree.
And the CAN devices do not have that property.

>> So at a first glance the CAN usage of IFF_LOOPBACK looks completely
>> broken, and likely to confuse other networking layers if they see
>> a CAN device.  Say if someone attempts to run IP over CAN or
>> something like that.
>>   
>
> The CAN protocol family is some kind of a closed ecosystem with a
> complete different addressing scheme that uses the bare networking
> functionality of the Linux Kernel as well as DECNET or ARCNET. You would
> never been able to run the IP-stack on a CAN netdev (ARPHDR_CAN,
> ETH_P_CAN) due to several technical differences in addressing, etc.

However when register_netdev is the netdev_notifier chain is called
with NETDEV_REGISTER

So then we enter code paths such as "net/ipv4/inetdev_event()" and
process the network device.  There is some small amount of treatment
given to devices that have IFF_LOOPBACK set.

The core point being that CAN devices as currently constructed are not
in a closed ecosystem.  Other networking layers see them even if they
can not use the properly.

I don't know what all of the implications are but I do know we
need to be careful.


>> Do you think you can remove this incompatible usage of IFF_LOOPBACK
>> from the can code?
>>   
>
> Yes. We might pick another name for it (see below).

Thanks.

>> If I have read your documentation properly the only reason you are
>> doing this is so that the timing of frames to cansniffer more
>> accurately reflects when the frame hits the wire.  If CAN runs over a
>> very slow medium I guess I can see where that can be a concern.

>
> So it's not an issue of having better timings but to reproduce the
> *correct message order* from the CAN bus. One year ago this problem has
> originally been pointed out by Michael Schulze from the University of
> Magdeburg as having a correct message order created by the CSMA/CA
> treatment is a vital requirement for CAN bus users. As you might see now
> the CAN netdriver has to offer additional functionalities due to the
> CSMA/CA treatment in opposite to the 'standard' CSMA/CD behaviour you
> know from Ethernet netdrivers. And this arbitration information of the
> CAN controller is only available on driver level. It is therefore no
> question IF the CAN netdriver supports the CSMA/CA treatment but HOW to
> provide an interface for this functionality on a basis of a standard
> netdriver (which simply only sends and receives frames).

Ok.  So the difference here is that CAN devices provide ordering on
the wire between their transmitted packets and their received packets,
and you need an additional hook so you can properly observe this case.

Hmm. My gut feel says that we just want function your drivers can
call post transmit that will call dev_queue_xmit_nit if someone else
is watching.  Although calling netif_rx seems to work but at least
in the general case with routing I would be concerned that would get
you into packets that would get routed out the incoming interface
and cause a loop.

> As the CAN netdrivers (as described above) are only available and used
> by the PF_CAN core, the use of IFF_LOOPBACK looked like reasonable
> solution to distinguish whether the CAN netdriver is capable to do the
> loopback (e.g. due to the ability of the controller to generate
> TX-interrupts) or not. The usage of IFF_LOOPBACK in CAN netdrivers
> didn't affect or confuse the rest of the Linux networking system up to
> now. Btw. if you state that IFF_LOOPBACK means for a netdriver, that
> "all packets from a device will come right back to the current machine,
> and go nowhere else.", we should think about a new IFF_-flag here.

Yes. IFF_LOOPBACK for a netdriver means that all packets from a device
will come right back to the current machine.   I stated that in a
later message, as that seems a clearer way to express what it means.

Further I still don't see any mechanism that isolates CAN netdrivers
from the other protocol layers.

What makes this problem a little stronger is that I have been
simplifying some of the tests in some of the other networking layers
from being "if (dev == loopback_dev)" to "if (dev->flags &
IFF_LOOPBACK)" So there are fewer special cases I need to deal with.

I believe that if you now use your current CAN patches unless I have
misread something your can devices will now show up with ip 127.0.0.1

> I don't have any concerns creating a new IFF_-flag for this "loopback
> approved by CSMA/CA media access" i just have no idea for a really good
> name for it. But maybe the use of IFF_LOOPBACK for CAN netdrivers
> (ARPHRD_CAN) is also ok for you now?!?

Serial devices tend to call this echo or local echo, so how about
IFF_ECHO.

Eric

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Eric W. Biederman wrote:
> Oliver Hartkopp <oliver@hartkopp.net> writes:  
>   
>> The CAN protocol family is some kind of a closed ecosystem with a
>> complete different addressing scheme that uses the bare networking
>> functionality of the Linux Kernel as well as DECNET or ARCNET. You would
>> never been able to run the IP-stack on a CAN netdev (ARPHDR_CAN,
>> ETH_P_CAN) due to several technical differences in addressing, etc.
>>     
>
> However when register_netdev is the netdev_notifier chain is called
> with NETDEV_REGISTER
>
> So then we enter code paths such as "net/ipv4/inetdev_event()" and
> process the network device.  There is some small amount of treatment
> given to devices that have IFF_LOOPBACK set.
>   

Yes. That's a good point. In the IPv4 NETDEV_REGISTER case the treatment
ends at the point, when (dev->mtu < 68) is checked as the CAN MTU is 16.
But we also had a problem with the IPv6 NETDEV_REGISTER in addr_conf
(fixed in 2.6.21) that complained about an interface with a too small MTU.

> The core point being that CAN devices as currently constructed are not
> in a closed ecosystem.  Other networking layers see them even if they
> can not use the properly.
>
> I don't know what all of the implications are but I do know we
> need to be careful.
>   

ACK.

>
> Hmm. My gut feel says that we just want function your drivers can
> call post transmit that will call dev_queue_xmit_nit if someone else
> is watching.  Although calling netif_rx seems to work but at least
> in the general case with routing I would be concerned that would get
> you into packets that would get routed out the incoming interface
> and cause a loop.
>   

All incoming (and even the 'echoed') CAN frames are processed in
can_rcv() to check the various CAN filters the users may have registered
through their different open AF_CAN sockets. This is a one way receive
path, that leads to simple a kfree_skb() if there's no subscriber for
the received frame. So there is no way to send CAN frames to a CAN
interface when is is not explicitly triggered from the user. CAN has no
routing by design. After looking into dev_queue_xmit_nit() it looks like
netif_rx() was a good choice.

>
> Further I still don't see any mechanism that isolates CAN netdrivers
> from the other protocol layers.
>
> What makes this problem a little stronger is that I have been
> simplifying some of the tests in some of the other networking layers
> from being "if (dev == loopback_dev)" to "if (dev->flags &
> IFF_LOOPBACK)" So there are fewer special cases I need to deal with.
>
> I believe that if you now use your current CAN patches unless I have
> misread something your can devices will now show up with ip 127.0.0.1
>   

No they don't due to the described mtu size verification. BUT i now get
an idea, why IFF_LOOPBACK was not that good approach ;-)

>   
>> I don't have any concerns creating a new IFF_-flag for this "loopback
>> approved by CSMA/CA media access" i just have no idea for a really good
>> name for it. But maybe the use of IFF_LOOPBACK for CAN netdrivers
>> (ARPHRD_CAN) is also ok for you now?!?
>>     
>
> Serial devices tend to call this echo or local echo, so how about
> IFF_ECHO.
>   

Excellent suggestion! If there are no remarks from other people, we can
change this in our next posting and add a new IFF_ECHO to if.h. Indeed
it's worth to look on the currently defined CAN RAW sockopts, the CAN
source and the docs to globally replace the 'loopback' with 'echo'. The
'local echo' hits the point really much better than to describe the
'loopback'-mechanic that's behind.

Thanks very much for your feedback & your time to review our stuff!

Oliver

[PATCH 0/7] CAN: Add new PF_CAN protocol family, try #6

[Urs Thuermann]

Hello Dave,

this is the sixth post of the patch series that adds the PF_CAN
protocol family for the Controller Area Network.

Since our last post we have changed the following:

* Update code to work with namespaces in net-2.6.24.
* Remove SET_MODULE_OWNER() from vcan.

The changes in try #5 were:

* Remove slab destructor from calls to kmem_cache_alloc().
* Add comments about types defined in can.h.
* Update comment on vcan loopback module parameter.
* Fix typo in documentation.

The changes in try #4 were:

* Change vcan network driver to use the new RTNL API, as suggested by
  Patrick.
* Revert our change to use skb->iif instead of skb->cb.  After
  discussion with Patrick and Jamal it turned out, our first
  implementation was correct.
* Use skb_tail_pointer() instead of skb->tail directly.
* Coding style changes to satisfy linux/scripts/checkpatch.pl.
* Minor changes for 64-bit-cleanliness.
* Minor cleanup of #include's

The changes in try #3 were:

* Use sbk->sk and skb->pkt_type instead of skb->cb to pass loopback
  flags and originating socket down to the driver and back to the
  receiving socket.  Thanks to Patrick McHardy for pointing out our
  wrong use of sbk->cb.
* Use skb->iif instead of skb->cb to pass receiving interface from
  raw_rcv() and bcm_rcv() up to raw_recvmsg() and bcm_recvmsg().
* Set skb->protocol when sending CAN frames to netdevices.
* Removed struct raw_opt and struct bcm_opt and integrated these
  directly into struct raw_sock and bcm_sock resp., like most other
  proto implementations do.
* We have found and fixed race conditions between raw_bind(),
  raw_{set,get}sockopt() and raw_notifier().  This resulted in
  - complete removal of our own notifier list infrastructure in
    af_can.c.  raw.c and bcm.c now use normal netdevice notifiers.
  - removal of ro->lock spinlock.  We use lock_sock(sk) now.
  - changed deletion of dev_rcv_lists, which are now marked for
    deletion in the netdevice notifier in af_can.c and are actually
    deleted when all entries have been deleted using can_rx_unregister().
* Follow changes in 2.6.22 (e.g. ktime_t timestamps in skb).
* Removed obsolete code from vcan.c, as pointed out by Stephen Hemminger.

The changes in try #2 were:

* reduced RCU callback overhead when deleting receiver lists (thx to
  feedback from Paul E. McKenney).
* eliminated some code duplication in net/can/proc.c.
* renamed slock-29 and sk_lock-29 to slock-AF_CAN and sk_lock-AF_CAN in
  net/core/sock.c
* added entry for can.txt in Documentation/networking/00-INDEX
* added error frame definitions in include/linux/can/error.h, which are to
  be used by CAN network drivers.


This patch series applies against net-2.6.24 and is derived from Subversion
revision r466 of http://svn.berlios.de/svnroot/repos/socketcan.
It can be found in the directory
http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/<version>.

This patch doesn't touch anything in the kernel except for the allocation
of a couple of numbers for protocol, arp hw type, and a line discipline.

Please review this patch series for integration into your tree.

Thanks very much for your work!

Best regards,

Urs Thuermann
Oliver Hartkopp
--

[PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

[-- Attachment #1: 05-can-vcan-driver.diff --]
[-- Type: text/plain, Size: 10324 bytes --]

This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 drivers/net/Makefile     |    1 
 drivers/net/can/Kconfig  |   25 ++++
 drivers/net/can/Makefile |    5 
 drivers/net/can/vcan.c   |  260 +++++++++++++++++++++++++++++++++++++++++++++++
 net/can/Kconfig          |    3 
 5 files changed, 294 insertions(+)

Index: net-2.6.24/drivers/net/Makefile
===================================================================
--- net-2.6.24.orig/drivers/net/Makefile	2007-09-17 10:30:35.000000000 +0200
+++ net-2.6.24/drivers/net/Makefile	2007-09-17 11:13:45.000000000 +0200
@@ -10,6 +10,7 @@
 obj-$(CONFIG_CHELSIO_T1) += chelsio/
 obj-$(CONFIG_CHELSIO_T3) += cxgb3/
 obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
 obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_ATL1) += atl1/
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: net-2.6.24/drivers/net/can/Kconfig
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/drivers/net/can/Kconfig	2007-09-17 11:13:45.000000000 +0200
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+	depends on CAN
+
+config CAN_VCAN
+	tristate "Virtual Local CAN Interface (vcan)"
+ 	depends on CAN
+	default N
+ 	---help---
+	  Similar to the network loopback devices, vcan offers a
+	  virtual local CAN interface.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called vcan.
+
+config CAN_DEBUG_DEVICES
+	bool "CAN devices debugging messages"
+	depends on CAN
+	default N
+	---help---
+	  Say Y here if you want the CAN device drivers to produce a bunch of
+	  debug messages to the system log.  Select this if you are having
+	  a problem with CAN support and want to see more of what is going
+	  on.
+
+endmenu
Index: net-2.6.24/drivers/net/can/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/drivers/net/can/Makefile	2007-09-17 11:13:45.000000000 +0200
@@ -0,0 +1,5 @@
+#
+#  Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN)		+= vcan.o
Index: net-2.6.24/drivers/net/can/vcan.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/drivers/net/can/vcan.c	2007-09-17 11:17:45.000000000 +0200
@@ -0,0 +1,260 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions, the following disclaimer and
+ *    the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/if_arp.h>
+#include <linux/if_ether.h>
+#include <linux/can.h>
+#include <net/rtnetlink.h>
+
+static __initdata const char banner[] =
+	KERN_INFO "vcan: Virtual CAN interface driver\n";
+
+MODULE_DESCRIPTION("virtual CAN interface");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
+
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+static int debug;
+module_param(debug, int, S_IRUGO);
+#endif
+
+/* To be moved to linux/can/dev.h */
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+#define DBG(args...)       (debug & 1 ? \
+			       (printk(KERN_DEBUG "vcan %s: ", __func__), \
+				printk(args)) : 0)
+#else
+#define DBG(args...)
+#endif
+
+
+/*
+ * CAN test feature:
+ * Enable the loopback on driver level for testing the CAN core loopback modes.
+ * See Documentation/networking/can.txt for details.
+ */
+
+static int loopback; /* loopback testing. Default: 0 (Off) */
+module_param(loopback, int, S_IRUGO);
+MODULE_PARM_DESC(loopback, "Loop back frames (for testing). Default: 0 (Off)");
+
+struct vcan_priv {
+	struct net_device *dev;
+	struct list_head list;
+};
+static LIST_HEAD(vcan_devs);
+
+static int vcan_open(struct net_device *dev)
+{
+	DBG("%s: interface up\n", dev->name);
+
+	netif_start_queue(dev);
+	return 0;
+}
+
+static int vcan_stop(struct net_device *dev)
+{
+	DBG("%s: interface down\n", dev->name);
+
+	netif_stop_queue(dev);
+	return 0;
+}
+
+static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+
+	stats->rx_packets++;
+	stats->rx_bytes += skb->len;
+
+	skb->protocol  = htons(ETH_P_CAN);
+	skb->pkt_type  = PACKET_BROADCAST;
+	skb->dev       = dev;
+	skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	DBG("received skbuff on interface %d\n", dev->ifindex);
+
+	netif_rx(skb);
+}
+
+static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+	int loop;
+
+	DBG("sending skbuff on interface %s\n", dev->name);
+
+	stats->tx_packets++;
+	stats->tx_bytes += skb->len;
+
+	/* set flag whether this packet has to be looped back */
+	loop = skb->pkt_type == PACKET_LOOPBACK;
+
+	if (!loopback) {
+		/* no loopback handling available inside this driver */
+
+		if (loop) {
+			/*
+			 * only count the packets here, because the
+			 * CAN core already did the loopback for us
+			 */
+			stats->rx_packets++;
+			stats->rx_bytes += skb->len;
+		}
+		kfree_skb(skb);
+		return 0;
+	}
+
+	/* perform standard loopback handling for CAN network interfaces */
+
+	if (loop) {
+		struct sock *srcsk = skb->sk;
+
+		if (atomic_read(&skb->users) != 1) {
+			struct sk_buff *old_skb = skb;
+
+			skb = skb_clone(old_skb, GFP_ATOMIC);
+			DBG(KERN_INFO "%s: %s: freeing old skbuff %p, "
+			    "using new skbuff %p\n",
+			    dev->name, __FUNCTION__, old_skb, skb);
+			kfree_skb(old_skb);
+			if (!skb)
+				return 0;
+		} else
+			skb_orphan(skb);
+
+		/* receive with packet counting */
+		skb->sk = srcsk;
+		vcan_rx(skb, dev);
+	} else {
+		/* no looped packets => no counting */
+		kfree_skb(skb);
+	}
+	return 0;
+}
+
+static void vcan_setup(struct net_device *dev)
+{
+	DBG("dev %s\n", dev->name);
+
+	dev->type              = ARPHRD_CAN;
+	dev->mtu               = sizeof(struct can_frame);
+	dev->hard_header_len   = 0;
+	dev->addr_len          = 0;
+	dev->tx_queue_len      = 0;
+	dev->flags             = IFF_NOARP;
+
+	/* set flags according to driver capabilities */
+	if (loopback)
+		dev->flags |= IFF_LOOPBACK;
+
+	dev->open              = vcan_open;
+	dev->stop              = vcan_stop;
+	dev->hard_start_xmit   = vcan_tx;
+	dev->destructor        = free_netdev;
+
+}
+
+static int vcan_newlink(struct net_device *dev,
+			struct nlattr *tb[], struct nlattr *data[])
+{
+	struct vcan_priv *priv = netdev_priv(dev);
+	int err;
+
+	err = register_netdevice(dev);
+	if (err < 0)
+		return err;
+
+	priv->dev = dev;
+	list_add_tail(&priv->list, &vcan_devs);
+	return 0;
+}
+
+static void vcan_dellink(struct net_device *dev)
+{
+	struct vcan_priv *priv = netdev_priv(dev);
+
+	list_del(&priv->list);
+	unregister_netdevice(dev);
+}
+
+static struct rtnl_link_ops vcan_link_ops __read_mostly = {
+       .kind           = "vcan",
+       .priv_size      = sizeof(struct vcan_priv),
+       .setup          = vcan_setup,
+       .newlink        = vcan_newlink,
+       .dellink        = vcan_dellink,
+};
+
+static __init int vcan_init_module(void)
+{
+	int err;
+
+	printk(banner);
+
+	if (loopback)
+		printk(KERN_INFO "vcan: enabled loopback on driver level.\n");
+
+	rtnl_lock();
+	err = __rtnl_link_register(&vcan_link_ops);
+	rtnl_unlock();
+	return err;
+}
+
+static __exit void vcan_cleanup_module(void)
+{
+	struct vcan_priv *priv, *n;
+
+	rtnl_lock();
+	list_for_each_entry_safe(priv, n, &vcan_devs, list)
+		vcan_dellink(priv->dev);
+	__rtnl_link_unregister(&vcan_link_ops);
+	rtnl_unlock();
+}
+
+module_init(vcan_init_module);
+module_exit(vcan_cleanup_module);
Index: net-2.6.24/net/can/Kconfig
===================================================================
--- net-2.6.24.orig/net/can/Kconfig	2007-09-17 11:12:30.000000000 +0200
+++ net-2.6.24/net/can/Kconfig	2007-09-17 11:13:45.000000000 +0200
@@ -77,3 +77,6 @@
 	  Say Y here if you want the CAN core to produce a bunch of debug
 	  messages to the system log.  Select this if you are having a
 	  problem with CAN support and want to see more of what is going on.
+
+
+source "drivers/net/can/Kconfig"

--

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Urs Thuermann wrote:
> This patch adds the virtual CAN bus (vcan) network driver.
> The vcan device is just a loopback device for CAN frames, no
> real CAN hardware is involved.
> 
> Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
> Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>
> 

Also looks mostly fine, a few comments below.

> +++ net-2.6.24/drivers/net/can/vcan.c	2007-09-17 11:17:45.000000000 +0200
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/netdevice.h>
> +#include <linux/if_arp.h>
> +#include <linux/if_ether.h>
> +#include <linux/can.h>
> +#include <net/rtnetlink.h>
> +
> +static __initdata const char banner[] =
> +	KERN_INFO "vcan: Virtual CAN interface driver\n";
> +
> +MODULE_DESCRIPTION("virtual CAN interface");
> +MODULE_LICENSE("Dual BSD/GPL");
> +MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
> +
> +#ifdef CONFIG_CAN_DEBUG_DEVICES
> +static int debug;
> +module_param(debug, int, S_IRUGO);
> +#endif
> +
> +/* To be moved to linux/can/dev.h */
> +#ifdef CONFIG_CAN_DEBUG_DEVICES
> +#define DBG(args...)       (debug & 1 ? \
> +			       (printk(KERN_DEBUG "vcan %s: ", __func__), \
> +				printk(args)) : 0)
> +#else
> +#define DBG(args...)
> +#endif
> +
> +
> +/*
> + * CAN test feature:
> + * Enable the loopback on driver level for testing the CAN core loopback modes.
> + * See Documentation/networking/can.txt for details.
> + */
> +
> +static int loopback; /* loopback testing. Default: 0 (Off) */
> +module_param(loopback, int, S_IRUGO);
> +MODULE_PARM_DESC(loopback, "Loop back frames (for testing). Default: 0 (Off)");


I would still prefer to have this on a per-device level configured
through netlink, but since we currently don't support specifying
flags for new devices anyways, I won't argue about it anymore
(OTOH, if you'd agree I could send a patch to add this feature
to the rtnl_link API).

> +
> +struct vcan_priv {
> +	struct net_device *dev;
> +	struct list_head list;
> +};


This is not needed anymore. The rtnl_link_unregister function calls
the ->dellink function for each device of this type. Check out the
current dummy.c driver.

> +static LIST_HEAD(vcan_devs);
> +
> +static int vcan_open(struct net_device *dev)
> +{
> +	DBG("%s: interface up\n", dev->name);
> +
> +	netif_start_queue(dev);
> +	return 0;
> +}
> +
> +static int vcan_stop(struct net_device *dev)
> +{
> +	DBG("%s: interface down\n", dev->name);
> +
> +	netif_stop_queue(dev);
> +	return 0;
> +}
> +
> +static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
> +{
> +	struct net_device_stats *stats = &dev->stats;
> +
> +	stats->rx_packets++;
> +	stats->rx_bytes += skb->len;
> +
> +	skb->protocol  = htons(ETH_P_CAN);
> +	skb->pkt_type  = PACKET_BROADCAST;
> +	skb->dev       = dev;
> +	skb->ip_summed = CHECKSUM_UNNECESSARY;
> +
> +	DBG("received skbuff on interface %d\n", dev->ifindex);
> +
> +	netif_rx(skb);
> +}
> +
> +static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
> +{
> +	struct net_device_stats *stats = &dev->stats;
> +	int loop;
> +
> +	DBG("sending skbuff on interface %s\n", dev->name);
> +
> +	stats->tx_packets++;
> +	stats->tx_bytes += skb->len;
> +
> +	/* set flag whether this packet has to be looped back */
> +	loop = skb->pkt_type == PACKET_LOOPBACK;
> +
> +	if (!loopback) {
> +		/* no loopback handling available inside this driver */
> +
> +		if (loop) {
> +			/*
> +			 * only count the packets here, because the
> +			 * CAN core already did the loopback for us
> +			 */
> +			stats->rx_packets++;
> +			stats->rx_bytes += skb->len;
> +		}
> +		kfree_skb(skb);
> +		return 0;
> +	}
> +
> +	/* perform standard loopback handling for CAN network interfaces */
> +
> +	if (loop) {
> +		struct sock *srcsk = skb->sk;
> +
> +		if (atomic_read(&skb->users) != 1) {
> +			struct sk_buff *old_skb = skb;
> +
> +			skb = skb_clone(old_skb, GFP_ATOMIC);
> +			DBG(KERN_INFO "%s: %s: freeing old skbuff %p, "
> +			    "using new skbuff %p\n",
> +			    dev->name, __FUNCTION__, old_skb, skb);
> +			kfree_skb(old_skb);

skb_share_check()?

> +			if (!skb)
> +				return 0;
> +		} else
> +			skb_orphan(skb);
> +
> +		/* receive with packet counting */
> +		skb->sk = srcsk;


Where is the socket used and what makes sure it still exists?

> +		vcan_rx(skb, dev);
> +	} else {
> +		/* no looped packets => no counting */
> +		kfree_skb(skb);
> +	}
> +	return 0;
> +}
> +
> +static void vcan_setup(struct net_device *dev)
> +{
> +	DBG("dev %s\n", dev->name);
> +
> +	dev->type              = ARPHRD_CAN;
> +	dev->mtu               = sizeof(struct can_frame);
> +	dev->hard_header_len   = 0;
> +	dev->addr_len          = 0;
> +	dev->tx_queue_len      = 0;
> +	dev->flags             = IFF_NOARP;
> +
> +	/* set flags according to driver capabilities */
> +	if (loopback)
> +		dev->flags |= IFF_LOOPBACK;
> +
> +	dev->open              = vcan_open;
> +	dev->stop              = vcan_stop;
> +	dev->hard_start_xmit   = vcan_tx;
> +	dev->destructor        = free_netdev;
> +
> +}
> +
> +static int vcan_newlink(struct net_device *dev,
> +			struct nlattr *tb[], struct nlattr *data[])
> +{
> +	struct vcan_priv *priv = netdev_priv(dev);
> +	int err;
> +
> +	err = register_netdevice(dev);
> +	if (err < 0)
> +		return err;
> +
> +	priv->dev = dev;
> +	list_add_tail(&priv->list, &vcan_devs);
> +	return 0;
> +}
> +
> +static void vcan_dellink(struct net_device *dev)
> +{
> +	struct vcan_priv *priv = netdev_priv(dev);
> +
> +	list_del(&priv->list);
> +	unregister_netdevice(dev);
> +}


Both the addlink and dellink function can be removed, the default
for addlink is register_netdevice, the default for unregister
is unregister_netdevice (and the list is not needed anymore as
mentioned above).

> +
> +static struct rtnl_link_ops vcan_link_ops __read_mostly = {
> +       .kind           = "vcan",
> +       .priv_size      = sizeof(struct vcan_priv),
> +       .setup          = vcan_setup,
> +       .newlink        = vcan_newlink,
> +       .dellink        = vcan_dellink,
> +};
> +
> +static __init int vcan_init_module(void)
> +{
> +	int err;
> +
> +	printk(banner);
> +
> +	if (loopback)
> +		printk(KERN_INFO "vcan: enabled loopback on driver level.\n");
> +
> +	rtnl_lock();
> +	err = __rtnl_link_register(&vcan_link_ops);
> +	rtnl_unlock();


Just using rtnl_link_register here is fine.

> +	return err;
> +}
> +
> +static __exit void vcan_cleanup_module(void)
> +{
> +	struct vcan_priv *priv, *n;
> +
> +	rtnl_lock();
> +	list_for_each_entry_safe(priv, n, &vcan_devs, list)
> +		vcan_dellink(priv->dev);
> +	__rtnl_link_unregister(&vcan_link_ops);
> +	rtnl_unlock();


and rtnl_link_unregister (without manual cleanup) here.

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

Patrick McHardy <kaber@trash.net> writes:

> > +static int loopback; /* loopback testing. Default: 0 (Off) */
> > +module_param(loopback, int, S_IRUGO);
> > +MODULE_PARM_DESC(loopback, "Loop back frames (for testing). Default: 0 (Off)");
> 
> 
> I would still prefer to have this on a per-device level configured
> through netlink, but since we currently don't support specifying
> flags for new devices anyways, I won't argue about it anymore
> (OTOH, if you'd agree I could send a patch to add this feature
> to the rtnl_link API).

Hm, somehow this topic comes up again and again.  I think there is
some misunderstanding about loopback in general and vcan, but I must
admit that our documentation until recently didn't describe this good
enough.  In fact, I think we also got better understanding from this
discussion and trying to explain this.

vcan is *not* a special loopback device like lo and it is not needed
to use PF_CAN.  Every CAN device driver should preferably loop back
frames sent by dev->hard_start_xmit() to netif_rx().  Since this is
unusual for netdevice drivers, the CAN core can do this itself as a
fallback for drivers that don't loopback.

For vcan it makes no difference whether loopback is done in the vcan
driver or in the CAN core.  No user will ever have to use this module
parameter.  Having a driver which can show both driver behaviors is
however useful for debugging our own code, to check whether the CAN
core does the right thing in both cases.

vcan is not a loopback device but a null device which simply discards
all sent frames since there is no hardware to send the frame to.  Like
other CAN drivers it can loop back the frame to the CAN core, but this
is not different from other CAN drivers.

It can be useful to have several vcan null devices so that different
apps can talk to each other through different interfaces.



Now I think we should consider removing the loopback code from
can_send() and demand from each CAN driver that it *has to* implement
this itself.

> > +
> > +struct vcan_priv {
> > +	struct net_device *dev;
> > +	struct list_head list;
> > +};
> 
> 
> This is not needed anymore. The rtnl_link_unregister function calls
> the ->dellink function for each device of this type. Check out the
> current dummy.c driver.

OK.

> > +		if (atomic_read(&skb->users) != 1) {
> > +			struct sk_buff *old_skb = skb;
> > +
> > +			skb = skb_clone(old_skb, GFP_ATOMIC);
> > +			DBG(KERN_INFO "%s: %s: freeing old skbuff %p, "
> > +			    "using new skbuff %p\n",
> > +			    dev->name, __FUNCTION__, old_skb, skb);
> > +			kfree_skb(old_skb);
> 
> skb_share_check()?

New to me.  I read that skb_share_check() decrements the refcount so I
am not sure it is we want.  Will take a look tomorrow.

> > +		/* receive with packet counting */
> > +		skb->sk = srcsk;
> 
> 
> Where is the socket used and what makes sure it still exists?

This socket pointer is used when the loopback frame is processed in
raw_rcv, only to compare it to the receiving socket to determine if
this frame was sent by the receiving socket itself.  The srcsk is only
compared, not dereferenced.

> > +static void vcan_dellink(struct net_device *dev)
> > +{
> > +	struct vcan_priv *priv = netdev_priv(dev);
> > +
> > +	list_del(&priv->list);
> > +	unregister_netdevice(dev);
> > +}
> 
> 
> Both the addlink and dellink function can be removed, the default
> for addlink is register_netdevice, the default for unregister
> is unregister_netdevice (and the list is not needed anymore as
> mentioned above).

OK, we'll remove them.

> > +	rtnl_lock();
> > +	err = __rtnl_link_register(&vcan_link_ops);
> > +	rtnl_unlock();
> 
> 
> Just using rtnl_link_register here is fine.

OK, we'll change that.

> and rtnl_link_unregister (without manual cleanup) here.

OK.

urs

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Urs Thuermann wrote:
> Now I think we should consider removing the loopback code from
> can_send() and demand from each CAN driver that it *has to* implement
> this itself.
>   

I also thought about this solution, which would remove the 'loopback'
parameter in vcan.c and some loopback code in can_send().

My only concern was, that this would break with standard netdev
behaviour just to send and receive data to/from the medium.
To break with the standard behaviour might be ok here as the PF_CAN only
deals with CAN netdevs (ARPHRD_CAN) which can be seen as some closed
eco-system. But i don't know what should happen, if someone in the
future gets the idea to route CAN-frames over ethernet devices for any
reason? In this case we would have to touch every driver we'd like to
support.

IMO it makes more sense to let the 9 lines of loopback fallback code in
can_send() than to remove it.

Oliver

Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Urs Thuermann wrote:
> Patrick McHardy <kaber@trash.net> writes:
> 
> 
>>>+static int loopback; /* loopback testing. Default: 0 (Off) */
>>>+module_param(loopback, int, S_IRUGO);
>>>+MODULE_PARM_DESC(loopback, "Loop back frames (for testing). Default: 0 (Off)");
>>
>>
>>I would still prefer to have this on a per-device level configured
>>through netlink, but since we currently don't support specifying
>>flags for new devices anyways, I won't argue about it anymore
>>(OTOH, if you'd agree I could send a patch to add this feature
>>to the rtnl_link API).
> 
> 
> Hm, somehow this topic comes up again and again.  I think there is
> some misunderstanding about loopback in general and vcan, but I must
> admit that our documentation until recently didn't describe this good
> enough.  In fact, I think we also got better understanding from this
> discussion and trying to explain this.
> 
> vcan is *not* a special loopback device like lo and it is not needed
> to use PF_CAN.  Every CAN device driver should preferably loop back
> frames sent by dev->hard_start_xmit() to netif_rx().  Since this is
> unusual for netdevice drivers, the CAN core can do this itself as a
> fallback for drivers that don't loopback.


I understood that from Oliver's explanations.

> For vcan it makes no difference whether loopback is done in the vcan
> driver or in the CAN core.  No user will ever have to use this module
> parameter.  Having a driver which can show both driver behaviors is
> however useful for debugging our own code, to check whether the CAN
> core does the right thing in both cases.
> 
> vcan is not a loopback device but a null device which simply discards
> all sent frames since there is no hardware to send the frame to.  Like
> other CAN drivers it can loop back the frame to the CAN core, but this
> is not different from other CAN drivers.
> 
> It can be useful to have several vcan null devices so that different
> apps can talk to each other through different interfaces.


My opinion is simply that stuff like that shouldn't be configured
through module parameters, but as I said, I don't want to get into
this discussion again, its not a big deal if you insist on keeping
it.

> Now I think we should consider removing the loopback code from
> can_send() and demand from each CAN driver that it *has to* implement
> this itself.


Really? I don't know about any other drivers, but it seems to make
sense to me to handle this in the core instead of reimplementing
it in every driver.

> 
> 
>>>+
>>>+struct vcan_priv {
>>>+	struct net_device *dev;
>>>+	struct list_head list;
>>>+};
>>
>>
>>This is not needed anymore. The rtnl_link_unregister function calls
>>the ->dellink function for each device of this type. Check out the
>>current dummy.c driver.
> 
> 
> OK.
> 
> 
>>>+		if (atomic_read(&skb->users) != 1) {
>>>+			struct sk_buff *old_skb = skb;
>>>+
>>>+			skb = skb_clone(old_skb, GFP_ATOMIC);
>>>+			DBG(KERN_INFO "%s: %s: freeing old skbuff %p, "
>>>+			    "using new skbuff %p\n",
>>>+			    dev->name, __FUNCTION__, old_skb, skb);
>>>+			kfree_skb(old_skb);
>>
>>skb_share_check()?
> 
> 
> New to me.  I read that skb_share_check() decrements the refcount so I
> am not sure it is we want.  Will take a look tomorrow.


It kfree_skb's the old skb, just as you do above.

> 
> 
>>>+		/* receive with packet counting */
>>>+		skb->sk = srcsk;
>>
>>
>>Where is the socket used and what makes sure it still exists?
> 
> 
> This socket pointer is used when the loopback frame is processed in
> raw_rcv, only to compare it to the receiving socket to determine if
> this frame was sent by the receiving socket itself.  The srcsk is only
> compared, not dereferenced.


Thanks for the explanation, that should be fine.

[patch 0/7] CAN: Add new PF_CAN protocol family, try #5

[Urs Thuermann]

Hello Dave,

this is the fifth post of the patch series that adds the PF_CAN
protocol family for the Controller Area Network.

Since our last post we have changed the following:

* Remove slab destructor from calls to kmem_cache_alloc().
* Add comments about types defined in can.h.
* Update comment on vcan loopback module parameter.
* Fix typo in documentation.

The changes in try #4 were:

* Change vcan network driver to use the new RTNL API, as suggested by
  Patrick.
* Revert our change to use skb->iif instead of skb->cb.  After
  discussion with Patrick and Jamal it turned out, our first
  implementation was correct.
* Use skb_tail_pointer() instead of skb->tail directly.
* Coding style changes to satisfy linux/scripts/checkpatch.pl.
* Minor changes for 64-bit-cleanliness.
* Minor cleanup of #include's

The changes in try #3 were:

* Use sbk->sk and skb->pkt_type instead of skb->cb to pass loopback
  flags and originating socket down to the driver and back to the
  receiving socket.  Thanks to Patrick McHardy for pointing out our
  wrong use of sbk->cb.
* Use skb->iif instead of skb->cb to pass receiving interface from
  raw_rcv() and bcm_rcv() up to raw_recvmsg() and bcm_recvmsg().
* Set skb->protocol when sending CAN frames to netdevices.
* Removed struct raw_opt and struct bcm_opt and integrated these
  directly into struct raw_sock and bcm_sock resp., like most other
  proto implementations do.
* We have found and fixed race conditions between raw_bind(),
  raw_{set,get}sockopt() and raw_notifier().  This resulted in
  - complete removal of our own notifier list infrastructure in
    af_can.c.  raw.c and bcm.c now use normal netdevice notifiers.
  - removal of ro->lock spinlock.  We use lock_sock(sk) now.
  - changed deletion of dev_rcv_lists, which are now marked for
    deletion in the netdevice notifier in af_can.c and are actually
    deleted when all entries have been deleted using can_rx_unregister().
* Follow changes in 2.6.22 (e.g. ktime_t timestamps in skb).
* Removed obsolete code from vcan.c, as pointed out by Stephen Hemminger.

The changes in try #2 were:

* reduced RCU callback overhead when deleting receiver lists (thx to
  feedback from Paul E. McKenney).
* eliminated some code duplication in net/can/proc.c.
* renamed slock-29 and sk_lock-29 to slock-AF_CAN and sk_lock-AF_CAN in
  net/core/sock.c
* added entry for can.txt in Documentation/networking/00-INDEX
* added error frame definitions in include/linux/can/error.h, which are to
  be used by CAN network drivers.


This patch series applies against net-2.6 and is derived from Subversion
revision r455 of http://svn.berlios.de/svnroot/repos/socketcan.
It can be found in the directory
http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/<version>.

This patch doesn't touch anything in the kernel except for the allocation
of a couple of numbers for protocol, arp hw type, and a line discipline.

Please review this patch series for integration into your tree.

Thanks very much for your work!

Best regards,

Urs Thuermann
Oliver Hartkopp

--

[patch 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

[-- Attachment #1: 05-can-vcan-driver.diff --]
[-- Type: text/plain, Size: 10311 bytes --]

This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 drivers/net/Makefile     |    1 
 drivers/net/can/Kconfig  |   25 ++++
 drivers/net/can/Makefile |    5 
 drivers/net/can/vcan.c   |  261 +++++++++++++++++++++++++++++++++++++++++++++++
 net/can/Kconfig          |    3 
 5 files changed, 295 insertions(+)

Index: net-2.6/drivers/net/Makefile
===================================================================
--- net-2.6.orig/drivers/net/Makefile	2007-08-03 11:21:31.000000000 +0200
+++ net-2.6/drivers/net/Makefile	2007-08-03 11:21:54.000000000 +0200
@@ -8,6 +8,7 @@
 obj-$(CONFIG_CHELSIO_T1) += chelsio/
 obj-$(CONFIG_CHELSIO_T3) += cxgb3/
 obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
 obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_ATL1) += atl1/
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: net-2.6/drivers/net/can/Kconfig
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6/drivers/net/can/Kconfig	2007-08-03 11:21:54.000000000 +0200
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+	depends on CAN
+
+config CAN_VCAN
+	tristate "Virtual Local CAN Interface (vcan)"
+ 	depends on CAN
+	default N
+ 	---help---
+	  Similar to the network loopback devices, vcan offers a
+	  virtual local CAN interface.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called vcan.
+
+config CAN_DEBUG_DEVICES
+	bool "CAN devices debugging messages"
+	depends on CAN
+	default N
+	---help---
+	  Say Y here if you want the CAN device drivers to produce a bunch of
+	  debug messages to the system log.  Select this if you are having
+	  a problem with CAN support and want to see more of what is going
+	  on.
+
+endmenu
Index: net-2.6/drivers/net/can/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6/drivers/net/can/Makefile	2007-08-03 11:21:54.000000000 +0200
@@ -0,0 +1,5 @@
+#
+#  Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN)		+= vcan.o
Index: net-2.6/drivers/net/can/vcan.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6/drivers/net/can/vcan.c	2007-08-03 11:21:54.000000000 +0200
@@ -0,0 +1,261 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions, the following disclaimer and
+ *    the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/if_arp.h>
+#include <linux/if_ether.h>
+#include <linux/can.h>
+#include <net/rtnetlink.h>
+
+static __initdata const char banner[] =
+	KERN_INFO "vcan: Virtual CAN interface driver\n";
+
+MODULE_DESCRIPTION("virtual CAN interface");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
+
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+static int debug;
+module_param(debug, int, S_IRUGO);
+#endif
+
+/* To be moved to linux/can/dev.h */
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+#define DBG(args...)       (debug & 1 ? \
+			       (printk(KERN_DEBUG "vcan %s: ", __func__), \
+				printk(args)) : 0)
+#else
+#define DBG(args...)
+#endif
+
+
+/*
+ * CAN test feature:
+ * Enable the loopback on driver level for testing the CAN core loopback modes.
+ * See Documentation/networking/can.txt for details.
+ */
+
+static int loopback; /* loopback testing. Default: 0 (Off) */
+module_param(loopback, int, S_IRUGO);
+MODULE_PARM_DESC(loopback, "Loop back frames (for testing). Default: 0 (Off)");
+
+struct vcan_priv {
+	struct net_device *dev;
+	struct list_head list;
+};
+static LIST_HEAD(vcan_devs);
+
+static int vcan_open(struct net_device *dev)
+{
+	DBG("%s: interface up\n", dev->name);
+
+	netif_start_queue(dev);
+	return 0;
+}
+
+static int vcan_stop(struct net_device *dev)
+{
+	DBG("%s: interface down\n", dev->name);
+
+	netif_stop_queue(dev);
+	return 0;
+}
+
+static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+
+	stats->rx_packets++;
+	stats->rx_bytes += skb->len;
+
+	skb->protocol  = htons(ETH_P_CAN);
+	skb->pkt_type  = PACKET_BROADCAST;
+	skb->dev       = dev;
+	skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	DBG("received skbuff on interface %d\n", dev->ifindex);
+
+	netif_rx(skb);
+}
+
+static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+	int loop;
+
+	DBG("sending skbuff on interface %s\n", dev->name);
+
+	stats->tx_packets++;
+	stats->tx_bytes += skb->len;
+
+	/* set flag whether this packet has to be looped back */
+	loop = skb->pkt_type == PACKET_LOOPBACK;
+
+	if (!loopback) {
+		/* no loopback handling available inside this driver */
+
+		if (loop) {
+			/*
+			 * only count the packets here, because the
+			 * CAN core already did the loopback for us
+			 */
+			stats->rx_packets++;
+			stats->rx_bytes += skb->len;
+		}
+		kfree_skb(skb);
+		return 0;
+	}
+
+	/* perform standard loopback handling for CAN network interfaces */
+
+	if (loop) {
+		struct sock *srcsk = skb->sk;
+
+		if (atomic_read(&skb->users) != 1) {
+			struct sk_buff *old_skb = skb;
+
+			skb = skb_clone(old_skb, GFP_ATOMIC);
+			DBG(KERN_INFO "%s: %s: freeing old skbuff %p, "
+			    "using new skbuff %p\n",
+			    dev->name, __FUNCTION__, old_skb, skb);
+			kfree_skb(old_skb);
+			if (!skb)
+				return 0;
+		} else
+			skb_orphan(skb);
+
+		/* receive with packet counting */
+		skb->sk = srcsk;
+		vcan_rx(skb, dev);
+	} else {
+		/* no looped packets => no counting */
+		kfree_skb(skb);
+	}
+	return 0;
+}
+
+static void vcan_setup(struct net_device *dev)
+{
+	DBG("dev %s\n", dev->name);
+
+	dev->type              = ARPHRD_CAN;
+	dev->mtu               = sizeof(struct can_frame);
+	dev->hard_header_len   = 0;
+	dev->addr_len          = 0;
+	dev->tx_queue_len      = 0;
+	dev->flags             = IFF_NOARP;
+
+	/* set flags according to driver capabilities */
+	if (loopback)
+		dev->flags |= IFF_LOOPBACK;
+
+	dev->open              = vcan_open;
+	dev->stop              = vcan_stop;
+	dev->hard_start_xmit   = vcan_tx;
+	dev->destructor        = free_netdev;
+
+	SET_MODULE_OWNER(dev);
+}
+
+static int vcan_newlink(struct net_device *dev,
+			struct nlattr *tb[], struct nlattr *data[])
+{
+	struct vcan_priv *priv = netdev_priv(dev);
+	int err;
+
+	err = register_netdevice(dev);
+	if (err < 0)
+		return err;
+
+	priv->dev = dev;
+	list_add_tail(&priv->list, &vcan_devs);
+	return 0;
+}
+
+static void vcan_dellink(struct net_device *dev)
+{
+	struct vcan_priv *priv = netdev_priv(dev);
+
+	list_del(&priv->list);
+	unregister_netdevice(dev);
+}
+
+static struct rtnl_link_ops vcan_link_ops __read_mostly = {
+       .kind           = "vcan",
+       .priv_size      = sizeof(struct vcan_priv),
+       .setup          = vcan_setup,
+       .newlink        = vcan_newlink,
+       .dellink        = vcan_dellink,
+};
+
+static __init int vcan_init_module(void)
+{
+	int err;
+
+	printk(banner);
+
+	if (loopback)
+		printk(KERN_INFO "vcan: enabled loopback on driver level.\n");
+
+	rtnl_lock();
+	err = __rtnl_link_register(&vcan_link_ops);
+	rtnl_unlock();
+	return err;
+}
+
+static __exit void vcan_cleanup_module(void)
+{
+	struct vcan_priv *priv, *n;
+
+	rtnl_lock();
+	list_for_each_entry_safe(priv, n, &vcan_devs, list)
+		vcan_dellink(priv->dev);
+	__rtnl_link_unregister(&vcan_link_ops);
+	rtnl_unlock();
+}
+
+module_init(vcan_init_module);
+module_exit(vcan_cleanup_module);
Index: net-2.6/net/can/Kconfig
===================================================================
--- net-2.6.orig/net/can/Kconfig	2007-08-03 11:21:51.000000000 +0200
+++ net-2.6/net/can/Kconfig	2007-08-03 11:21:54.000000000 +0200
@@ -77,3 +77,6 @@
 	  Say Y here if you want the CAN core to produce a bunch of debug
 	  messages to the system log.  Select this if you are having a
 	  problem with CAN support and want to see more of what is going on.
+
+
+source "drivers/net/can/Kconfig"

--

[patch 0/7] CAN: Add new PF_CAN protocol family, try #3

[Urs Thuermann]

Hello Dave,

this is the third post of the patch series that adds the PF_CAN
protocol family for the Controller Area Network.

Since our last post we have changed the code quite a lot:

* Use sbk->sk and skb->pkt_type instead of skb->cb to pass loopback
  flags and originating socket down to the driver and back to the
  receiving socket.  Thanks to Patrick McHardy for pointing out our
  wrong use of sbk->cb.

* Use skb->iif instead of skb->cb to pass receiving interface from
  raw_rcv() and bcm_rcv() up to raw_recvmsg() and bcm_recvmsg().
  
* Set skb->protocol when sending CAN frames to netdevices.

* Removed struct raw_opt and struct bcm_opt and integrated these
  directly into struct raw_sock and bcm_sock resp., like most other
  proto implementations do.

* We have found and fixed race conditions between raw_bind(),
  raw_{set,get}sockopt() and raw_notifier().  This resulted in
  - complete removal of our own notifier list infrastructure in
    af_can.c.  raw.c and bcm.c now use normal netdevice notifiers.
  - removal of ro->lock spinlock.  We use lock_sock(sk) now.
  - changed deletion of dev_rcv_lists, which are now marked for
    deletion in the netdevice notifier in af_can.c and are actually
    deleted when all entries have been deleted using can_rx_unregister().

* Follow changes in 2.6.22 (e.g. ktime_t timestamps in skb).

* Removed obsolete code from vcan.c, as pointed out by Stephen Hemminger.

This patch series applies against linux-2.6.22-rc5-git5 and is derived from
Subversion revision r390 of http://svn.berlios.de/svnroot/repos/socketcan.
It can be found in the directory
http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/<version>.

This patch doesn't touch anything in the kernel except for the allocation
of a couple of numbers for protocol, arp hw type, and a line discipline.

Please consider this patch series for integration into your tree.

Thanks very much for your work!

Best regards,

Urs Thuermann
Oliver Hartkopp
--

[patch 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

[-- Attachment #1: 05-can-vcan-driver.diff --]
[-- Type: text/plain, Size: 11271 bytes --]

This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.

Signed-Off-By: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-Off-By: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 drivers/net/Makefile     |    1 
 drivers/net/can/Kconfig  |   25 ++++
 drivers/net/can/Makefile |    5 
 drivers/net/can/vcan.c   |  287 +++++++++++++++++++++++++++++++++++++++++++++++
 net/can/Kconfig          |    3 
 5 files changed, 321 insertions(+)

Index: linux-2.6.22-rc5/drivers/net/Makefile
===================================================================
--- linux-2.6.22-rc5.orig/drivers/net/Makefile	2007-06-20 14:10:41.000000000 +0200
+++ linux-2.6.22-rc5/drivers/net/Makefile	2007-06-20 14:11:19.000000000 +0200
@@ -8,6 +8,7 @@
 obj-$(CONFIG_CHELSIO_T1) += chelsio/
 obj-$(CONFIG_CHELSIO_T3) += cxgb3/
 obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
 obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_ATL1) += atl1/
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: linux-2.6.22-rc5/drivers/net/can/Kconfig
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.22-rc5/drivers/net/can/Kconfig	2007-06-20 14:11:19.000000000 +0200
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+	depends on CAN
+
+config CAN_VCAN
+	tristate "Virtual Local CAN Interface (vcan)"
+ 	depends on CAN
+	default N
+ 	---help---
+	  Similar to the network loopback devices, vcan offers a
+	  virtual local CAN interface.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called vcan.
+
+config CAN_DEBUG_DEVICES
+	bool "CAN devices debugging messages"
+	depends on CAN
+	default N
+	---help---
+	  Say Y here if you want the CAN device drivers to produce a bunch of
+	  debug messages to the system log.  Select this if you are having
+	  a problem with CAN support and want to see more of what is going
+	  on.
+
+endmenu
Index: linux-2.6.22-rc5/drivers/net/can/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.22-rc5/drivers/net/can/Makefile	2007-06-20 14:11:19.000000000 +0200
@@ -0,0 +1,5 @@
+#
+#  Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN)		+= vcan.o
Index: linux-2.6.22-rc5/drivers/net/can/vcan.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.22-rc5/drivers/net/can/vcan.c	2007-06-20 14:11:19.000000000 +0200
@@ -0,0 +1,287 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions, the following disclaimer and
+ *    the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/if_arp.h>
+#include <linux/if_ether.h>
+#include <linux/can.h>
+
+static __initdata const char banner[] =
+	KERN_INFO "vcan: Virtual CAN interface driver\n";
+
+MODULE_DESCRIPTION("virtual CAN interface");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
+
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+static int debug = 0;
+module_param(debug, int, S_IRUGO);
+#endif
+
+/* To be moved to linux/can/dev.h */
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+#define DBG(args...)       (debug & 1 ? \
+			       (printk(KERN_DEBUG "vcan %s: ", __func__), \
+				printk(args)) : 0)
+#else
+#define DBG(args...)
+#endif
+
+#define STATSIZE sizeof(struct net_device_stats)
+
+static int numdev = 4; /* default number of virtual CAN interfaces */
+module_param(numdev, int, S_IRUGO);
+MODULE_PARM_DESC(numdev, "Number of virtual CAN devices");
+
+/*
+ * CAN network devices *should* support a local loopback functionality
+ * (see Documentation/networking/can.txt). To test the handling of CAN
+ * interfaces that do not support the loopback both driver types are
+ * implemented inside this vcan driver. In the case that the driver does
+ * not support the loopback the IFF_LOOPBACK remains clear in dev->flags.
+ * This causes the PF_CAN core to perform the loopback as a fallback solution.
+ */
+
+static int loopback = 0; /* vcan default: no loopback, just free the skb */
+module_param(loopback, int, S_IRUGO);
+MODULE_PARM_DESC(loopback, "Loop back sent frames. vcan default: 0 (Off)");
+
+static struct net_device **vcan_devs; /* root pointer to netdevice structs */
+
+static int vcan_open(struct net_device *dev)
+{
+	DBG("%s: interface up\n", dev->name);
+
+	netif_start_queue(dev);
+	return 0;
+}
+
+static int vcan_stop(struct net_device *dev)
+{
+	DBG("%s: interface down\n", dev->name);
+
+	netif_stop_queue(dev);
+	return 0;
+}
+
+static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = netdev_priv(dev);
+
+	stats->rx_packets++;
+	stats->rx_bytes += skb->len;
+
+	skb->protocol  = htons(ETH_P_CAN);
+	skb->pkt_type  = PACKET_BROADCAST;
+	skb->dev       = dev;
+	skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	DBG("received skbuff on interface %d\n", dev->ifindex);
+
+	netif_rx(skb);
+}
+
+static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = netdev_priv(dev);
+	int loop;
+
+	DBG("sending skbuff on interface %s\n", dev->name);
+
+	stats->tx_packets++;
+	stats->tx_bytes += skb->len;
+
+	/* set flag whether this packet has to be looped back */
+	loop = skb->pkt_type == PACKET_LOOPBACK;
+
+	if (!loopback) {
+		/* no loopback handling available inside this driver */
+
+		if (loop) {
+			/*
+			 * only count the packets here, because the
+			 * CAN core already did the loopback for us
+			 */
+			stats->rx_packets++;
+			stats->rx_bytes += skb->len;
+		}
+		kfree_skb(skb);
+		return 0;
+	}
+
+	/* perform standard loopback handling for CAN network interfaces */
+
+	if (loop) {
+		struct sock *srcsk = skb->sk;
+
+		if (atomic_read(&skb->users) != 1) {
+			struct sk_buff *old_skb = skb;
+
+			skb = skb_clone(old_skb, GFP_ATOMIC);
+			DBG(KERN_INFO "%s: %s: freeing old skbuff %p, "
+			    "using new skbuff %p\n",
+			    dev->name, __FUNCTION__, old_skb, skb);
+			kfree_skb(old_skb);
+			if (!skb)
+				return 0;
+		} else
+			skb_orphan(skb);
+
+		/* receive with packet counting */
+		skb->sk = srcsk;
+		vcan_rx(skb, dev);
+	} else {
+		/* no looped packets => no counting */
+		kfree_skb(skb);
+	}
+	return 0;
+}
+
+static struct net_device_stats *vcan_get_stats(struct net_device *dev)
+{
+	struct net_device_stats *stats = netdev_priv(dev);
+
+	return stats;
+}
+
+static void vcan_init(struct net_device *dev)
+{
+	DBG("dev %s\n", dev->name);
+
+	ether_setup(dev);
+
+	memset(dev->priv, 0, STATSIZE);
+
+	dev->type              = ARPHRD_CAN;
+	dev->mtu               = sizeof(struct can_frame);
+	dev->flags             = IFF_NOARP;
+
+	/* set flags according to driver capabilities */
+	if (loopback)
+		dev->flags |= IFF_LOOPBACK;
+
+	dev->open              = vcan_open;
+	dev->stop              = vcan_stop;
+	dev->hard_start_xmit   = vcan_tx;
+	dev->get_stats         = vcan_get_stats;
+
+	SET_MODULE_OWNER(dev);
+}
+
+static __init int vcan_init_module(void)
+{
+	int i, result;
+
+	printk(banner);
+
+	/* register at least one interface */
+	if (numdev < 1)
+		numdev = 1;
+
+	printk(KERN_INFO
+	       "vcan: registering %d virtual CAN interfaces. (loopback %s)\n",
+	       numdev, loopback ? "enabled" : "disabled");
+
+	vcan_devs = kzalloc(numdev * sizeof(struct net_device *), GFP_KERNEL);
+	if (!vcan_devs) {
+		printk(KERN_ERR "vcan: Can't allocate vcan devices array!\n");
+		return -ENOMEM;
+	}
+
+	for (i = 0; i < numdev; i++) {
+		vcan_devs[i] = alloc_netdev(STATSIZE, "vcan%d", vcan_init);
+		if (!vcan_devs[i]) {
+			printk(KERN_ERR "vcan: error allocating net_device\n");
+			result = -ENOMEM;
+			goto out;
+		}
+
+		result = register_netdev(vcan_devs[i]);
+		if (result < 0) {
+			printk(KERN_ERR
+			       "vcan: error %d registering interface %s\n",
+			       result, vcan_devs[i]->name);
+			free_netdev(vcan_devs[i]);
+			vcan_devs[i] = NULL;
+			goto out;
+
+		} else {
+			DBG("successfully registered interface %s\n",
+			    vcan_devs[i]->name);
+		}
+	}
+
+	return 0;
+
+ out:
+	for (i = 0; i < numdev; i++) {
+		if (vcan_devs[i]) {
+			unregister_netdev(vcan_devs[i]);
+			free_netdev(vcan_devs[i]);
+		}
+	}
+
+	kfree(vcan_devs);
+
+	return result;
+}
+
+static __exit void vcan_cleanup_module(void)
+{
+	int i;
+
+	for (i = 0; i < numdev; i++) {
+		if (vcan_devs[i]) {
+			unregister_netdev(vcan_devs[i]);
+			free_netdev(vcan_devs[i]);
+		}
+	}
+
+	kfree(vcan_devs);
+}
+
+module_init(vcan_init_module);
+module_exit(vcan_cleanup_module);
Index: linux-2.6.22-rc5/net/can/Kconfig
===================================================================
--- linux-2.6.22-rc5.orig/net/can/Kconfig	2007-06-20 14:11:13.000000000 +0200
+++ linux-2.6.22-rc5/net/can/Kconfig	2007-06-20 14:11:19.000000000 +0200
@@ -77,3 +77,6 @@
 	  Say Y here if you want the CAN core to produce a bunch of debug
 	  messages to the system log.  Select this if you are having a
 	  problem with CAN support and want to see more of what is going on.
+
+
+source "drivers/net/can/Kconfig"

--

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Urs Thuermann wrote:
> This patch adds the virtual CAN bus (vcan) network driver.
> The vcan device is just a loopback device for CAN frames, no
> real CAN hardware is involved.


Is there a reason why you're still doing the "allocate n devices
on init" thing instead of using the rtnl_link API?

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

Patrick McHardy <kaber@trash.net> writes:

> Is there a reason why you're still doing the "allocate n devices
> on init" thing instead of using the rtnl_link API?

Sorry, it's simply a matter of time.  We have been extremely busy with
other projects and two presentations (mgmt, customers, and press) the
last two weeks and have worked on the other changes this week.  I'm
sorry I haven't yet been able to look at your rtnl_link code close
enough, but it's definitely on my todo list.  Starting on Sunday I'll
be on a business trip to .jp for a week, and I hope I get to it in
that week, otherwise on return.

urs

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Urs Thuermann wrote:
> Patrick McHardy <kaber@trash.net> writes:
> 
> 
>>Is there a reason why you're still doing the "allocate n devices
>>on init" thing instead of using the rtnl_link API?
> 
> 
> Sorry, it's simply a matter of time.  We have been extremely busy with
> other projects and two presentations (mgmt, customers, and press) the
> last two weeks and have worked on the other changes this week.  I'm
> sorry I haven't yet been able to look at your rtnl_link code close
> enough, but it's definitely on my todo list.  Starting on Sunday I'll
> be on a business trip to .jp for a week, and I hope I get to it in
> that week, otherwise on return.


Sorry, but busy is no reason for merging code that has deprecated
(at least by me :)) behaviour. Please change this before submitting
for inclusion.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Patrick McHardy wrote:
> Urs Thuermann wrote:
>   
>> Patrick McHardy <kaber@trash.net> writes:
>>
>>
>>     
>>> Is there a reason why you're still doing the "allocate n devices
>>> on init" thing instead of using the rtnl_link API?
>>>       
>> Sorry, it's simply a matter of time.  We have been extremely busy with
>> other projects and two presentations (mgmt, customers, and press) the
>> last two weeks and have worked on the other changes this week.  I'm
>> sorry I haven't yet been able to look at your rtnl_link code close
>> enough, but it's definitely on my todo list.  Starting on Sunday I'll
>> be on a business trip to .jp for a week, and I hope I get to it in
>> that week, otherwise on return.
>>     
>
>
> Sorry, but busy is no reason for merging code that has deprecated
> (at least by me :)) behaviour. Please change this before submitting
> for inclusion.
>   

Dear Patrick,

i was just looking through the mailings regarding your suggested changes
(e.g. in VLAN, DUMMY and IFB) an none of them currently went into the
kernel and the discussion on some topics (especially in the VLAN case)
is just running.

I just got an impression of what you intend to have and it looks
reasonable and good to me. But anyhow it's in process and therefore i
won't like to be the first adopter as you might comprehend. It is no
question, that we would update to your approach as it is part of the
kernel, finalized in discussion and somewhat stable. But it doesn't look
adequate to me to push us to support your brand new approach as some
kind of gate for an inclusion into the mainstream kernel :-(

So for me it looks like, that we should get the feedback from Jamal if
our usage of skb->iif fits the intention of skb->iif and if we should
set the incoming interface index ourselves of if we let
netif_receive_skb() do this job. After that discussion i currently can
not see any reason, why the PF_CAN support should not go into the
mainstream kernel. I daily get positive community feedback about this
matching implementation for the Linux kernel and it's elegant manner of
usage for application programmers.

On our TODO list there is the netlink support as well as the usage of
hrtimers in our broadcast manager - but both have no vital influence to
the new protocol family PF_CAN and therefore it should not slow down the
inclusion process. Be sure that we'll support netlink immediately, when
it hits the road for other drivers also.

Best regards,
Oliver

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Oliver Hartkopp wrote:
> Patrick McHardy wrote:
> 
>>>
>>>Sorry, it's simply a matter of time.  We have been extremely busy with
>>>other projects and two presentations (mgmt, customers, and press) the
>>>last two weeks and have worked on the other changes this week.  I'm
>>>sorry I haven't yet been able to look at your rtnl_link code close
>>>enough, but it's definitely on my todo list.  Starting on Sunday I'll
>>>be on a business trip to .jp for a week, and I hope I get to it in
>>>that week, otherwise on return.
>>>    
>>
>>
>>Sorry, but busy is no reason for merging code that has deprecated
>>(at least by me :)) behaviour. Please change this before submitting
>>for inclusion.
>>  
> 
> i was just looking through the mailings regarding your suggested changes
> (e.g. in VLAN, DUMMY and IFB) an none of them currently went into the
> kernel and the discussion on some topics (especially in the VLAN case)
> is just running.


They are all in the net-2.6.23 tree.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Patrick McHardy wrote:
> Oliver Hartkopp wrote:
>   
>> i was just looking through the mailings regarding your suggested changes
>> (e.g. in VLAN, DUMMY and IFB) an none of them currently went into the
>> kernel (..)
>>     
>
>
> They are all in the net-2.6.23 tree.
>   

Ah, ok - that wasn't on my radar as i missed the mail from Dave to you
at June 13th ...

@Dave: Please consider to schedule the PF_CAN stuff for inclusion into
2.6.23 also. Thx.

Btw. for next week, we'll ...

1. ... wait for Jamals feedback about skb->iif usage
2. ... move the vcan driver for the new netlink API

So that we can finally go for net-2.6.23 at the end of next week, if
there are no new issues from other reviewers until then.

@Patrick: The changes in dummy.c and ifb.c for the netlink support do
not look very complicated (not even for me ;-)) When these changes are
implemented, how do i create/remove my interfaces? Is there any
userspace tool like 'tc' for that?

Thx & regards,
Oliver

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Oliver Hartkopp wrote:
> @Patrick: The changes in dummy.c and ifb.c for the netlink support do
> not look very complicated (not even for me ;-))


I have a patch to make it even simpler, it basically needs only
the rtnl_link_ops structures initialized with one or two members
for devices like dummy and ifb. Will push once we're through the
patches I sent recently, until then please use the current interface.

> When these changes are
> implemented, how do i create/remove my interfaces? Is there any
> userspace tool like 'tc' for that?


Its "ip". I think I've CCed you or one of your colleagues on
the patches, otherwise please check the list. For a device like
yours it only needs the patch implementing general RTM_NEWLINK
support, unless you want to make the loopback parameter
configurable, in which case you would need to add something
like iplink_vlan that parses the parameter.

BTW, in case the loopback device is required for normal
operation it might make sense to create *one* device by
default, but four identical devices seems a bit extreme.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Patrick McHardy wrote:
>
> BTW, in case the loopback device is required for normal
> operation it might make sense to create *one* device by
> default, but four identical devices seems a bit extreme.
>
>   

As i wrote before CAN addressing consists of CAN-Identifiers and the
used interface. The use of four vcan's is definitely a usual case!

Oliver

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Oliver Hartkopp wrote:
> Patrick McHardy wrote:
> 
>>BTW, in case the loopback device is required for normal
>>operation it might make sense to create *one* device by
>>default, but four identical devices seems a bit extreme.
>
> 
> As i wrote before CAN addressing consists of CAN-Identifiers and the
> used interface. The use of four vcan's is definitely a usual case!


It should create as many devices as necessary to operate (similar
to the loopback device) by default. Optional interfaces that are
used for addressing reasons should be manually added by the user
as needed. And it should not use module parameters for that please.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

Patrick McHardy <kaber@trash.net> writes:

> It should create as many devices as necessary to operate (similar
> to the loopback device) by default. Optional interfaces that are
> used for addressing reasons should be manually added by the user
> as needed. And it should not use module parameters for that please.

I have now changed vcan to use the netlink interface.  I am now
thinking about how many interfaces should be created at module load
time.

The PF_CAN doesn't need vcan to operate, like lo for IP.  vcan is
mostly for doing tests when you don't have real CAN interfaces
available, and you would normally want to have as many vcan devices as
you would have real CAN interface on your target hardware.

This is why I also wanted to have a default of 0 vcan interfaces and
an ioctl do add interfaces as needed.  Then we decided however to have
a module parameter with a typical default and no ioctl().

Now, I would again think that 0 vcan interfaces should be created
automatically and the user must create the devices he needs.  Wouldn't
that also be a better default for dummy interfaces?  It would simplify
dummy.c quite a bit, since dummy_init_one() could be removed
completely and dummy_init_module() would only register the
dummy_link_ops, right?

However, this could surprise a user loading the module and not seeing
any new interface.  Is it because of backward compatibility that you
create one dummy interface by default?

For this reason I also consider a default of one vcan interface to be
created automatically.  But then 1 seems almost as arbitrarily as 4,
since also 1 is not needed for PF_CAN to work.

I currently still prefer no default interfaces, since we would get rid
of some code.

What is the reason you don't like a module parameter to control the
number of default interfaces?  We still have that in our code
currently (but I'm about to remove it).

urs

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Urs Thuermann wrote:
> Patrick McHardy <kaber@trash.net> writes:
> 
> 
>>It should create as many devices as necessary to operate (similar
>>to the loopback device) by default. Optional interfaces that are
>>used for addressing reasons should be manually added by the user
>>as needed. And it should not use module parameters for that please.
> 
> 
> I have now changed vcan to use the netlink interface.  I am now
> thinking about how many interfaces should be created at module load
> time.
> 
> The PF_CAN doesn't need vcan to operate, like lo for IP.  vcan is
> mostly for doing tests when you don't have real CAN interfaces
> available, and you would normally want to have as many vcan devices as
> you would have real CAN interface on your target hardware.
> 
> This is why I also wanted to have a default of 0 vcan interfaces and
> an ioctl do add interfaces as needed.  Then we decided however to have
> a module parameter with a typical default and no ioctl().
> 
> Now, I would again think that 0 vcan interfaces should be created
> automatically and the user must create the devices he needs.  Wouldn't
> that also be a better default for dummy interfaces?  It would simplify
> dummy.c quite a bit, since dummy_init_one() could be removed
> completely and dummy_init_module() would only register the
> dummy_link_ops, right?
>
> However, this could surprise a user loading the module and not seeing
> any new interface.  Is it because of backward compatibility that you
> create one dummy interface by default?


Yes, unfortunately we can't change this.

> For this reason I also consider a default of one vcan interface to be
> created automatically.  But then 1 seems almost as arbitrarily as 4,
> since also 1 is not needed for PF_CAN to work.
> 
> I currently still prefer no default interfaces, since we would get rid
> of some code.


Me too, and you don't need to worry about compatibility.

> What is the reason you don't like a module parameter to control the
> number of default interfaces?  We still have that in our code
> currently (but I'm about to remove it).


There's nothing wrong with the parameter itself as long as its
not the only way to control things. But I don't see why you'd
need it when you can simply add them at runtime. Especially when
you don't build it as module this is a lot easier.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

Patrick McHardy <kaber@trash.net> writes:

> > I currently still prefer no default interfaces, since we would get rid
> > of some code.
> 
> 
> Me too, and you don't need to worry about compatibility.

Here is a new version of the vcan driver for you to review.  We now
use the netlink link creation API and no interfaces will be created at
module load time.  The module parameter for the number of interfaces
to be created has been removed.

I have appended the patch at the end of this mail.

We have also made some changes to the rest of the PF_CAN code, here is
the complete list of changes:

* Change vcan network driver to use the new RTNL API.

* Revert our change to use skb->iif instead of skb->cb.  After
  discussion with Patrick and Jamal it turned out, our first
  implementation was correct.
 
* Use skb_tail_pointer() instead of skb->tail directly.

* Minor changes for 64-bit-cleanliness.

* Minor cleanup of #include's

The current patch series can be found at
http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/net-2.6.23

Could you please review this again?  Should we post the whole patch
series to netdev ML again?

Regards,
urs



This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.

Signed-Off-By: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-Off-By: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 drivers/net/Makefile     |    1 
 drivers/net/can/Kconfig  |   25 ++++
 drivers/net/can/Makefile |    5 
 drivers/net/can/vcan.c   |  264 +++++++++++++++++++++++++++++++++++++++++++++++
 net/can/Kconfig          |    3 
 5 files changed, 298 insertions(+)

Index: net-2.6.23/drivers/net/Makefile
===================================================================
--- net-2.6.23.orig/drivers/net/Makefile	2007-07-09 10:41:38.000000000 +0200
+++ net-2.6.23/drivers/net/Makefile	2007-07-09 10:42:01.000000000 +0200
@@ -8,6 +8,7 @@
 obj-$(CONFIG_CHELSIO_T1) += chelsio/
 obj-$(CONFIG_CHELSIO_T3) += cxgb3/
 obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
 obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_ATL1) += atl1/
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: net-2.6.23/drivers/net/can/Kconfig
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.23/drivers/net/can/Kconfig	2007-07-09 10:42:01.000000000 +0200
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+	depends on CAN
+
+config CAN_VCAN
+	tristate "Virtual Local CAN Interface (vcan)"
+ 	depends on CAN
+	default N
+ 	---help---
+	  Similar to the network loopback devices, vcan offers a
+	  virtual local CAN interface.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called vcan.
+
+config CAN_DEBUG_DEVICES
+	bool "CAN devices debugging messages"
+	depends on CAN
+	default N
+	---help---
+	  Say Y here if you want the CAN device drivers to produce a bunch of
+	  debug messages to the system log.  Select this if you are having
+	  a problem with CAN support and want to see more of what is going
+	  on.
+
+endmenu
Index: net-2.6.23/drivers/net/can/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.23/drivers/net/can/Makefile	2007-07-09 10:42:01.000000000 +0200
@@ -0,0 +1,5 @@
+#
+#  Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN)		+= vcan.o
Index: net-2.6.23/drivers/net/can/vcan.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.23/drivers/net/can/vcan.c	2007-07-09 13:22:44.000000000 +0200
@@ -0,0 +1,264 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions, the following disclaimer and
+ *    the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/if_arp.h>
+#include <linux/if_ether.h>
+#include <linux/can.h>
+#include <net/rtnetlink.h>
+
+static __initdata const char banner[] =
+	KERN_INFO "vcan: Virtual CAN interface driver\n";
+
+MODULE_DESCRIPTION("virtual CAN interface");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
+
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+static int debug = 0;
+module_param(debug, int, S_IRUGO);
+#endif
+
+/* To be moved to linux/can/dev.h */
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+#define DBG(args...)       (debug & 1 ? \
+			       (printk(KERN_DEBUG "vcan %s: ", __func__), \
+				printk(args)) : 0)
+#else
+#define DBG(args...)
+#endif
+
+
+/*
+ * CAN network devices *should* support a local loopback functionality
+ * (see Documentation/networking/can.txt). To test the handling of CAN
+ * interfaces that do not support the loopback both driver types are
+ * implemented inside this vcan driver. In the case that the driver does
+ * not support the loopback the IFF_LOOPBACK remains clear in dev->flags.
+ * This causes the PF_CAN core to perform the loopback as a fallback solution.
+ */
+
+static int loopback = 0; /* vcan default: no loopback, just free the skb */
+module_param(loopback, int, S_IRUGO);
+MODULE_PARM_DESC(loopback, "Loop back sent frames. vcan default: 0 (Off)");
+
+struct vcan_priv {
+	struct net_device *dev;
+	struct list_head list;
+};
+static LIST_HEAD(vcan_devs);
+
+static int vcan_open(struct net_device *dev)
+{
+	DBG("%s: interface up\n", dev->name);
+
+	netif_start_queue(dev);
+	return 0;
+}
+
+static int vcan_stop(struct net_device *dev)
+{
+	DBG("%s: interface down\n", dev->name);
+
+	netif_stop_queue(dev);
+	return 0;
+}
+
+static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+
+	stats->rx_packets++;
+	stats->rx_bytes += skb->len;
+
+	skb->protocol  = htons(ETH_P_CAN);
+	skb->pkt_type  = PACKET_BROADCAST;
+	skb->dev       = dev;
+	skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	DBG("received skbuff on interface %d\n", dev->ifindex);
+
+	netif_rx(skb);
+}
+
+static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+	int loop;
+
+	DBG("sending skbuff on interface %s\n", dev->name);
+
+	stats->tx_packets++;
+	stats->tx_bytes += skb->len;
+
+	/* set flag whether this packet has to be looped back */
+	loop = skb->pkt_type == PACKET_LOOPBACK;
+
+	if (!loopback) {
+		/* no loopback handling available inside this driver */
+
+		if (loop) {
+			/*
+			 * only count the packets here, because the
+			 * CAN core already did the loopback for us
+			 */
+			stats->rx_packets++;
+			stats->rx_bytes += skb->len;
+		}
+		kfree_skb(skb);
+		return 0;
+	}
+
+	/* perform standard loopback handling for CAN network interfaces */
+
+	if (loop) {
+		struct sock *srcsk = skb->sk;
+
+		if (atomic_read(&skb->users) != 1) {
+			struct sk_buff *old_skb = skb;
+
+			skb = skb_clone(old_skb, GFP_ATOMIC);
+			DBG(KERN_INFO "%s: %s: freeing old skbuff %p, "
+			    "using new skbuff %p\n",
+			    dev->name, __FUNCTION__, old_skb, skb);
+			kfree_skb(old_skb);
+			if (!skb)
+				return 0;
+		} else
+			skb_orphan(skb);
+
+		/* receive with packet counting */
+		skb->sk = srcsk;
+		vcan_rx(skb, dev);
+	} else {
+		/* no looped packets => no counting */
+		kfree_skb(skb);
+	}
+	return 0;
+}
+
+static void vcan_setup(struct net_device *dev)
+{
+	DBG("dev %s\n", dev->name);
+
+	dev->type              = ARPHRD_CAN;
+	dev->mtu               = sizeof(struct can_frame);
+	dev->hard_header_len   = 0;
+	dev->addr_len          = 0;
+	dev->tx_queue_len      = 0;
+	dev->flags             = IFF_NOARP;
+
+	/* set flags according to driver capabilities */
+	if (loopback)
+		dev->flags |= IFF_LOOPBACK;
+
+	dev->open              = vcan_open;
+	dev->stop              = vcan_stop;
+	dev->hard_start_xmit   = vcan_tx;
+	dev->destructor        = free_netdev;
+
+	SET_MODULE_OWNER(dev);
+}
+
+static int vcan_newlink(struct net_device *dev,
+			struct nlattr *tb[], struct nlattr *data[])
+{
+	struct vcan_priv *priv = netdev_priv(dev);
+	int err;
+
+	err = register_netdevice(dev);
+	if (err < 0)
+		return err;
+
+	priv->dev = dev;
+	list_add_tail(&priv->list, &vcan_devs);
+	return 0;
+}
+
+static void vcan_dellink(struct net_device *dev)
+{
+	struct vcan_priv *priv = netdev_priv(dev);
+
+	list_del(&priv->list);
+	unregister_netdevice(dev);
+}
+
+static struct rtnl_link_ops vcan_link_ops __read_mostly = {
+       .kind           = "vcan",
+       .priv_size      = sizeof(struct vcan_priv),
+       .setup          = vcan_setup,
+       .newlink        = vcan_newlink,
+       .dellink        = vcan_dellink,
+};
+
+static __init int vcan_init_module(void)
+{
+	int err;
+
+	printk(banner);
+
+	if (loopback)
+		printk(KERN_INFO "vcan: enabled loopback on driver level.\n");
+
+	rtnl_lock();
+	err = __rtnl_link_register(&vcan_link_ops);
+	rtnl_unlock();
+	return err;
+}
+
+static __exit void vcan_cleanup_module(void)
+{
+	struct vcan_priv *priv, *n;
+
+	rtnl_lock();
+	list_for_each_entry_safe(priv, n, &vcan_devs, list)
+		vcan_dellink(priv->dev);
+	__rtnl_link_unregister(&vcan_link_ops);
+	rtnl_unlock();
+}
+
+module_init(vcan_init_module);
+module_exit(vcan_cleanup_module);
Index: net-2.6.23/net/can/Kconfig
===================================================================
--- net-2.6.23.orig/net/can/Kconfig	2007-07-09 10:41:58.000000000 +0200
+++ net-2.6.23/net/can/Kconfig	2007-07-09 10:42:01.000000000 +0200
@@ -77,3 +77,6 @@
 	  Say Y here if you want the CAN core to produce a bunch of debug
 	  messages to the system log.  Select this if you are having a
 	  problem with CAN support and want to see more of what is going on.
+
+
+source "drivers/net/can/Kconfig"

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Urs Thuermann wrote:
> + * CAN network devices *should* support a local loopback functionality
> + * (see Documentation/networking/can.txt). To test the handling of CAN
> + * interfaces that do not support the loopback both driver types are
> + * implemented inside this vcan driver. In the case that the driver does
> + * not support the loopback the IFF_LOOPBACK remains clear in dev->flags.
> + * This causes the PF_CAN core to perform the loopback as a fallback solution.
> + */
> +
> +static int loopback = 0; /* vcan default: no loopback, just free the skb */
> +module_param(loopback, int, S_IRUGO);
> +MODULE_PARM_DESC(loopback, "Loop back sent frames. vcan default: 0 (Off)");

...

> +static void vcan_setup(struct net_device *dev)
> +{
> +	DBG("dev %s\n", dev->name);
> +
> +	dev->type              = ARPHRD_CAN;
> +	dev->mtu               = sizeof(struct can_frame);
> +	dev->hard_header_len   = 0;
> +	dev->addr_len          = 0;
> +	dev->tx_queue_len      = 0;
> +	dev->flags             = IFF_NOARP;
> +
> +	/* set flags according to driver capabilities */
> +	if (loopback)
> +		dev->flags |= IFF_LOOPBACK;


Still configuration of the network device based on module parameters.
What about people that want loopback and non-loopback devices at the
same time?

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Patrick McHardy wrote:
> Urs Thuermann wrote:
>   
>> (..) To test the handling of CAN
>> + * interfaces that do not support the loopback both driver types are
>> + * implemented inside this vcan driver.
>> (..)
>>     
>
> Still configuration of the network device based on module parameters.
> What about people that want loopback and non-loopback devices at the
> same time?
>   

Hi Patrick,

the people get the loopback functionality in ANY case. There is indeed
no difference from the view of the users, if you change this switch.

The possibility to enable the loopback on vcan driver level is only to ...

1. Test the loopback fallback code in af_can.c
2. Show, how a correct loopback handling is to be implemented

... nothing more.

Regarding point 1: The code is well tested now.
Regarding point 2: Even if code is the best documentation in many cases,
the loopback functionality may also be 'documented' in another way.

I had a short discussion with Urs about that. Please select:

[ ] Let it like it is
[ ] Remove the whole loopback functionality (as it is only test code for
a different module)
[ ] Remove the module parameter and make it a #define VCAN_LOOPBACK for
testing

:-)

Thanks & best regards,
Oliver

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Hi Patrick,

what's your opinion about my reply to your remark?

Should we just change the module parameter from "loopback" to
"loopbacktest" to make the test intention obvious?
Or should we remove the loopback test functionality?

Regards,
Oliver

Oliver Hartkopp wrote:
> Patrick McHardy wrote:
>   
>> Urs Thuermann wrote:
>>   
>>     
>>> (..) To test the handling of CAN
>>> + * interfaces that do not support the loopback both driver types are
>>> + * implemented inside this vcan driver.
>>> (..)
>>>     
>>>       
>> Still configuration of the network device based on module parameters.
>> What about people that want loopback and non-loopback devices at the
>> same time?
>>   
>>     
>
> Hi Patrick,
>
> the people get the loopback functionality in ANY case. There is indeed
> no difference from the view of the users, if you change this switch.
>
> The possibility to enable the loopback on vcan driver level is only to ...
>
> 1. Test the loopback fallback code in af_can.c
> 2. Show, how a correct loopback handling is to be implemented
>
> ... nothing more.
>
> Regarding point 1: The code is well tested now.
> Regarding point 2: Even if code is the best documentation in many cases,
> the loopback functionality may also be 'documented' in another way.
>
> I had a short discussion with Urs about that. Please select:
>
> [ ] Let it like it is
> [ ] Remove the whole loopback functionality (as it is only test code for
> a different module)
> [ ] Remove the module parameter and make it a #define VCAN_LOOPBACK for
> testing
>
> :-)
>
> Thanks & best regards,
> Oliver
>
> -
> 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
>
>   

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Oliver Hartkopp wrote:
> Hi Patrick,
> 
> what's your opinion about my reply to your remark?
> 
> Should we just change the module parameter from "loopback" to
> "loopbacktest" to make the test intention obvious?
> Or should we remove the loopback test functionality?


I'll look into it tommorrow, please be patient.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

-------- Original-Message --------
Subject: Re: [patch 5/7] CAN: Add virtual CAN netdevice driver
Date: Thu, 12 Jul 2007 00:52:58 +0200
From: Patrick McHardy <kaber@trash.net>
To: Oliver Hartkopp <oliver@hartkopp.net>

Patrick McHardy wrote:
> Oliver Hartkopp wrote:
>   
>> Hi Patrick,
>>
>> what's your opinion about my reply to your remark?
>>     
> I'll look into it tommorrow, please be patient.
>   

I am.

This issue has blocked any ongoing activities for one week now.
You also won't be happy if someone raises objections on your code and
then vanishes for discussions for a week (except on other topics on the ML).
Take 2(!) minutes from your valuable time to *understand* the loopback
testing feature and you'll recognize that your remark completely missed
the point.

Thanks.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[David Miller]

From: Oliver Hartkopp <oliver@hartkopp.net>
Date: Mon, 16 Jul 2007 08:05:49 +0200

> This issue has blocked any ongoing activities for one week now.

Too bad, Patrick is a volunteer just like any other netdev contributor
and you cannot dictate when he or anyone else devotes his or her time
to reviewing your work.

And because it is their choice when and if to review your work,
if you are pushy or have a bad attitude this will cause it to
take even longer.

So just be patient.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Oliver Hartkopp wrote:
> This issue has blocked any ongoing activities for one week now.
> You also won't be happy if someone raises objections on your code and
> then vanishes for discussions for a week (except on other topics on the ML).
> Take 2(!) minutes from your valuable time to *understand* the loopback
> testing feature and you'll recognize that your remark completely missed
> the point.


Possible. You could have spent your time working on other obvious
issues, I'm pretty certain running scripts/checkpatch will show
you quite a few.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Patrick McHardy wrote:
> Possible. You could have spent your time working on other obvious
> issues, I'm pretty certain running scripts/checkpatch will show
> you quite a few.
>   

Ugh! Indeed! Thanks for the hint!! I'll fix this immediately.

Is there anything else that can be checked beforehand?

Regards,
Oliver

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Oliver Hartkopp wrote:
> Patrick McHardy wrote:
> 
>>Still configuration of the network device based on module parameters.
>>What about people that want loopback and non-loopback devices at the
>>same time?
>>  
> 
> the people get the loopback functionality in ANY case. There is indeed
> no difference from the view of the users, if you change this switch.
> 
> The possibility to enable the loopback on vcan driver level is only to ...
> 
> 1. Test the loopback fallback code in af_can.c
> 2. Show, how a correct loopback handling is to be implemented
> 
> ... nothing more.


So its the "correct" handling and the other one is only fallback? That
still sounds like it wants proper configuration. How does loopback work
without this driver?

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Patrick McHardy wrote:
> Oliver Hartkopp wrote:
>   
>> the people get the loopback functionality in ANY case. There is indeed
>> no difference from the view of the users, if you change this switch.
>>
>> The possibility to enable the loopback on vcan driver level is only to ...
>>
>> 1. Test the loopback fallback code in af_can.c
>> 2. Show, how a correct loopback handling is to be implemented
>>
>> ... nothing more.
>>     
>
>
> So its the "correct" handling and the other one is only fallback? That
> still sounds like it wants proper configuration. How does loopback work
> without this driver?
>   

As the addressing in CAN consist of a CAN-identifier and a CAN-interface
you always have at least one available CAN-interface you are working on.
In our case we may have several virtual CAN-interfaces.

On the CAN bus there is a CSMA/CA access with arbitration by the
CAN-identifier.
Due to the arbitration on the CAN bus the _transmission_ of a low prio
CAN-ID
may be delayed from the _receipition_ of a high prio CAN frame. To
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 to perform the loopback for
some reason the PF_CAN core can do this task as a fallback solution.

There are low cost adapters that are connected via some kind of ASCII
protocol on a serial line. These low cost adapters do not provide any TX
acknowledge that may be used to initiate the loopback receiption for the
sent CAN-frame . They are really dumb.

So you can divide the CAN controller drivers into two classes:

1. With an ACK (e.g. a valid TX interrupt) to trigger the loopback of
the sent frame
2. Without any feedback (the dumb one)

The intelligent ones (1.) do set dev->flags = (IFF_NOARP | IFF_LOOPBACK);
The dumb ones (2.) only set dev->flags = IFF_NOARP;

If a CAN-frame has to be looped back (the default), the function
can_send() in af_can.c looks whether the interface is capable to perform
the loopback or not (by checking the IFF_LOOPBACK flag in dev->flags).
In the case of a dumb interface the CAN-frame is looped back
immediately. In the case of an intelligent interface the CAN core keeps
it's hands off and lets the interface do the loopback. This should be
the usual case.

The loopback module parameter in the vcan driver enables or disables the
loopback on driver level, to test whether the fallback functionality for
'dumb interfaces' in af_can.c is working properly or not. Maybe it
should therefore be renamed to 'testloopback' or it should be removed
completely.

>From the functional side the user is not able to feel any difference
whether the loopback test is enabled in the vcan driver or not.

Thanks very much for your feedback!

Best regards,
Oliver

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[David Miller]

From: Oliver Hartkopp <oliver@hartkopp.net>
Date: Sat, 23 Jun 2007 17:13:21 +0200

> Patrick McHardy wrote:
> > Oliver Hartkopp wrote:
> >   
> >> i was just looking through the mailings regarding your suggested changes
> >> (e.g. in VLAN, DUMMY and IFB) an none of them currently went into the
> >> kernel (..)
> >>     
> >
> >
> > They are all in the net-2.6.23 tree.
> >   
> 
> Ah, ok - that wasn't on my radar as i missed the mail from Dave to you
> at June 13th ...
> 
> @Dave: Please consider to schedule the PF_CAN stuff for inclusion into
> 2.6.23 also. Thx.

No.  Fix your code to use the correct interfaces and suggestions
from Patrick.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

David Miller wrote:
> From: Oliver Hartkopp <oliver@hartkopp.net>
> Date: Sat, 23 Jun 2007 17:13:21 +0200
>
>   
>> @Dave: Please consider to schedule the PF_CAN stuff for inclusion into
>> 2.6.23 also. Thx.
>>     
>>
>
> No.  Fix your code to use the correct interfaces and suggestions
> from Patrick.
>   

The part Patrick gave his feedback to is only one part (a sample network
diver) of the PF_CAN stuff, that maybe left out for the first inclusion.
So this kind request was only to set a marker that there is something
coming up in any case.

Thx & best regards,
Oliver

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[David Miller]

From: Oliver Hartkopp <oliver@hartkopp.net>
Date: Sat, 23 Jun 2007 14:05:43 +0200

> i was just looking through the mailings regarding your suggested changes
> (e.g. in VLAN, DUMMY and IFB) an none of them currently went into the
> kernel and the discussion on some topics (especially in the VLAN case)
> is just running.

This code is in the net-2.6 GIT tree of mine at:

	master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git

which is what you should be doing all of your networking
development against, and generating patches against, anyways.

Anything in that tree is scheduled for 2.6.23 inclusion, therefore
if a preferred interface has been added there, you better use it
for any new code.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

David Miller wrote:
> This code is in the net-2.6 GIT tree of mine at:
>
> 	master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git
>
> which is what you should be doing all of your networking
> development against, and generating patches against, anyways.
>
> Anything in that tree is scheduled for 2.6.23 inclusion, therefore
> if a preferred interface has been added there, you better use it
> for any new code.
>   

Ok - thanks for the advise.
It's our first real inclusion (besides some patches) and of course we
want to do our best.
We'll continue to provide patches against net-2.6.

Thx.
Oliver

[patch 0/7] CAN: Add new PF_CAN protocol family, update

[Urs Thuermann]

Hello Dave,

this is the second post of the patch series that adds the PF_CAN
protocol family for the Controller Area Network.

Due to some feedback on the netdev-list and own reviews we have changed
the following:

* reduced RCU callback overhead when deleting receiver lists (thx to
  feedback from Paul E. McKenney).

* eliminated some code duplication in net/can/proc.c.

* renamed slock-29 and sk_lock-29 to slock-AF_CAN and sk_lock-AF_CAN in
  net/core/sock.c

* added entry for can.txt in Documentation/networking/00-INDEX

* added error frame definitions in include/linux/can/error.h, which are to
  be used by CAN network drivers.

This patch series applies against linux-2.6.22-rc3 and is derived from
Subversion revision r322 of http://svn.berlios.de/svnroot/repos/socketcan.
It doesn't touch anything in the kernel except for the allocation of a
couple of numbers for protocol, arp hw type, and a line discipline.

The realization of PF_CAN has been started at the end of 2002 and is
stable since mid-2006.  It's used in automation, naval applications and
several automotive R&D environments (e.g. for the Car2Car onboard unit in
http://www.its.dot.gov/vii).

Since, the code has been heavily used and tested and has been reviewed and
discussed intensively on the project mailing lists, we do not expect any
vital problems in this patch series.
Please apply it after a final review.

Thanks very much for your work!

Best regards,

Urs Thuermann
Oliver Hartkopp

--

[patch 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

[-- Attachment #1: 05-can-vcan-driver.diff --]
[-- Type: text/plain, Size: 11802 bytes --]

This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.

Signed-Off-By: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-Off-By: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 drivers/net/Makefile     |    1 
 drivers/net/can/Kconfig  |   25 +++
 drivers/net/can/Makefile |    5 
 drivers/net/can/vcan.c   |  308 +++++++++++++++++++++++++++++++++++++++++++++++
 net/can/Kconfig          |    3 
 5 files changed, 342 insertions(+)

Index: linux-2.6.22-rc3/drivers/net/Makefile
===================================================================
--- linux-2.6.22-rc3.orig/drivers/net/Makefile	2007-05-30 14:56:39.000000000 +0200
+++ linux-2.6.22-rc3/drivers/net/Makefile	2007-05-30 14:58:04.000000000 +0200
@@ -8,6 +8,7 @@
 obj-$(CONFIG_CHELSIO_T1) += chelsio/
 obj-$(CONFIG_CHELSIO_T3) += cxgb3/
 obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
 obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_ATL1) += atl1/
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: linux-2.6.22-rc3/drivers/net/can/Kconfig
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.22-rc3/drivers/net/can/Kconfig	2007-05-30 14:58:05.000000000 +0200
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+	depends on CAN
+
+config CAN_VCAN
+	tristate "Virtual Local CAN Interface (vcan)"
+ 	depends on CAN
+	default N
+ 	---help---
+	  Similar to the network loopback devices, vcan offers a
+	  virtual local CAN interface.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called vcan.
+
+config CAN_DEBUG_DEVICES
+	bool "CAN devices debugging messages"
+	depends on CAN
+	default N
+	---help---
+	  Say Y here if you want the CAN device drivers to produce a bunch of
+	  debug messages to the system log.  Select this if you are having
+	  a problem with CAN support and want to see more of what is going
+	  on.
+
+endmenu
Index: linux-2.6.22-rc3/drivers/net/can/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.22-rc3/drivers/net/can/Makefile	2007-05-30 14:58:05.000000000 +0200
@@ -0,0 +1,5 @@
+#
+#  Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN)		+= vcan.o
Index: linux-2.6.22-rc3/drivers/net/can/vcan.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.22-rc3/drivers/net/can/vcan.c	2007-05-30 14:58:05.000000000 +0200
@@ -0,0 +1,308 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions, the following disclaimer and
+ *    the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/if_arp.h>
+#include <linux/if_ether.h>
+#include <linux/can.h>
+
+static __initdata const char banner[] =
+	KERN_INFO "vcan: Virtual CAN interface driver\n";
+
+MODULE_DESCRIPTION("virtual CAN interface");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
+
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+static int debug = 0;
+module_param(debug, int, S_IRUGO);
+#endif
+
+/* To be moved to linux/can/dev.h */
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+#define DBG(args...)       (debug & 1 ? \
+			       (printk(KERN_DEBUG "vcan %s: ", __func__), \
+				printk(args)) : 0)
+#else
+#define DBG(args...)
+#endif
+
+#define STATSIZE sizeof(struct net_device_stats)
+
+static int numdev = 4; /* default number of virtual CAN interfaces */
+module_param(numdev, int, S_IRUGO);
+MODULE_PARM_DESC(numdev, "Number of virtual CAN devices");
+
+/*
+ * CAN network devices *should* support a local loopback functionality
+ * (see Documentation/networking/can.txt). To test the handling of CAN
+ * interfaces that do not support the loopback both driver types are
+ * implemented inside this vcan driver. In the case that the driver does
+ * not support the loopback the IFF_LOOPBACK remains clear in dev->flags.
+ * This causes the PF_CAN core to perform the loopback as a fallback solution.
+ */
+
+static int loopback = 0; /* vcan default: no loopback, just free the skb */
+module_param(loopback, int, S_IRUGO);
+MODULE_PARM_DESC(loopback, "Loop back sent frames. vcan default: 0 (Off)");
+
+static struct net_device **vcan_devs; /* root pointer to netdevice structs */
+
+static int vcan_open(struct net_device *dev)
+{
+	DBG("%s: interface up\n", dev->name);
+
+	netif_start_queue(dev);
+	return 0;
+}
+
+static int vcan_stop(struct net_device *dev)
+{
+	DBG("%s: interface down\n", dev->name);
+
+	netif_stop_queue(dev);
+	return 0;
+}
+
+static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = netdev_priv(dev);
+
+	stats->rx_packets++;
+	stats->rx_bytes += skb->len;
+
+	skb->protocol  = htons(ETH_P_CAN);
+	skb->dev       = dev;
+	skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	DBG("received skbuff on interface %d\n", dev->ifindex);
+
+	netif_rx(skb);
+}
+
+static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = netdev_priv(dev);
+	int loop;
+
+	DBG("sending skbuff on interface %s\n", dev->name);
+
+	stats->tx_packets++;
+	stats->tx_bytes += skb->len;
+
+	/* tx socket reference pointer: Loopback required if not NULL */
+	loop = *(struct sock **)skb->cb != NULL;
+
+	if (!loopback) {
+		/* no loopback handling available inside this driver */
+
+		if (loop) {
+			/*
+			 * only count the packets here, because the
+			 * CAN core already did the loopback for us
+			 */
+			stats->rx_packets++;
+			stats->rx_bytes += skb->len;
+		}
+		kfree_skb(skb);
+		return 0;
+	}
+
+	/* perform standard loopback handling for CAN network interfaces */
+
+	if (loop) {
+		if (atomic_read(&skb->users) != 1) {
+			struct sk_buff *old_skb = skb;
+
+			skb = skb_clone(old_skb, GFP_ATOMIC);
+			DBG(KERN_INFO "%s: %s: freeing old skbuff %p, "
+			    "using new skbuff %p\n",
+			    dev->name, __FUNCTION__, old_skb, skb);
+			kfree_skb(old_skb);
+			if (!skb)
+				return 0;
+		} else
+			skb_orphan(skb);
+
+		/* receive with packet counting */
+		vcan_rx(skb, dev);
+	} else {
+		/* no looped packets => no counting */
+		kfree_skb(skb);
+	}
+	return 0;
+}
+
+static int vcan_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
+{
+	return -EOPNOTSUPP;
+}
+
+static int vcan_rebuild_header(struct sk_buff *skb)
+{
+	DBG("skbuff %p\n", skb);
+	return 0;
+}
+
+static int vcan_header(struct sk_buff *skb, struct net_device *dev,
+		       unsigned short type, void *daddr, void *saddr,
+		       unsigned int len)
+{
+	DBG("skbuff %p, device %p\n", skb, dev);
+	return 0;
+}
+
+
+static struct net_device_stats *vcan_get_stats(struct net_device *dev)
+{
+	struct net_device_stats *stats = netdev_priv(dev);
+
+	return stats;
+}
+
+static void vcan_init(struct net_device *dev)
+{
+	DBG("dev %s\n", dev->name);
+
+	ether_setup(dev);
+
+	memset(dev->priv, 0, STATSIZE);
+
+	dev->type              = ARPHRD_CAN;
+	dev->mtu               = sizeof(struct can_frame);
+	dev->flags             = IFF_NOARP;
+
+	/* set flags according to driver capabilities */
+	if (loopback)
+		dev->flags |= IFF_LOOPBACK;
+
+	dev->open              = vcan_open;
+	dev->stop              = vcan_stop;
+	dev->set_config        = NULL;
+	dev->hard_start_xmit   = vcan_tx;
+	dev->do_ioctl          = vcan_ioctl;
+	dev->get_stats         = vcan_get_stats;
+	dev->hard_header       = vcan_header;
+	dev->rebuild_header    = vcan_rebuild_header;
+	dev->hard_header_cache = NULL;
+
+	SET_MODULE_OWNER(dev);
+}
+
+static __init int vcan_init_module(void)
+{
+	int i, result;
+
+	printk(banner);
+
+	/* register at least one interface */
+	if (numdev < 1)
+		numdev = 1;
+
+	printk(KERN_INFO
+	       "vcan: registering %d virtual CAN interfaces. (loopback %s)\n",
+	       numdev, loopback ? "enabled" : "disabled");
+
+	vcan_devs = kzalloc(numdev * sizeof(struct net_device *), GFP_KERNEL);
+	if (!vcan_devs) {
+		printk(KERN_ERR "vcan: Can't allocate vcan devices array!\n");
+		return -ENOMEM;
+	}
+
+	for (i = 0; i < numdev; i++) {
+		vcan_devs[i] = alloc_netdev(STATSIZE, "vcan%d", vcan_init);
+		if (!vcan_devs[i]) {
+			printk(KERN_ERR "vcan: error allocating net_device\n");
+			result = -ENOMEM;
+			goto out;
+		}
+
+		result = register_netdev(vcan_devs[i]);
+		if (result < 0) {
+			printk(KERN_ERR
+			       "vcan: error %d registering interface %s\n",
+			       result, vcan_devs[i]->name);
+			free_netdev(vcan_devs[i]);
+			vcan_devs[i] = NULL;
+			goto out;
+
+		} else {
+			DBG("successfully registered interface %s\n",
+			    vcan_devs[i]->name);
+		}
+	}
+
+	return 0;
+
+ out:
+	for (i = 0; i < numdev; i++) {
+		if (vcan_devs[i]) {
+			unregister_netdev(vcan_devs[i]);
+			free_netdev(vcan_devs[i]);
+		}
+	}
+
+	kfree(vcan_devs);
+
+	return result;
+}
+
+static __exit void vcan_cleanup_module(void)
+{
+	int i;
+
+	for (i = 0; i < numdev; i++) {
+		if (vcan_devs[i]) {
+			unregister_netdev(vcan_devs[i]);
+			free_netdev(vcan_devs[i]);
+		}
+	}
+
+	kfree(vcan_devs);
+}
+
+module_init(vcan_init_module);
+module_exit(vcan_cleanup_module);
Index: linux-2.6.22-rc3/net/can/Kconfig
===================================================================
--- linux-2.6.22-rc3.orig/net/can/Kconfig	2007-05-30 14:58:03.000000000 +0200
+++ linux-2.6.22-rc3/net/can/Kconfig	2007-05-30 14:58:05.000000000 +0200
@@ -77,3 +77,6 @@
 	  Say Y here if you want the CAN core to produce a bunch of debug
 	  messages to the system log.  Select this if you are having a
 	  problem with CAN support and want to see more of what is going on.
+
+
+source "drivers/net/can/Kconfig"

--

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Urs Thuermann wrote:
> +static int numdev = 4; /* default number of virtual CAN interfaces */
> +module_param(numdev, int, S_IRUGO);
> +MODULE_PARM_DESC(numdev, "Number of virtual CAN devices");


I have a set of patches coming up that introduce a rtnetlink API
for adding/modifying/deleting software network devices. I would
prefer if you could switch this driver over instead of doing the
"create N devices during loading" that many current drivers do,
leaving you with 20 unused devices after boot.

> +static int loopback = 0; /* vcan default: no loopback, just free the skb */
> +module_param(loopback, int, S_IRUGO);
> +MODULE_PARM_DESC(loopback, "Loop back sent frames. vcan default: 0 (Off)");


And it allows you have both loopback and non-loopback devices
in case that would be useful.

I'll send the patches by Friday.

> +static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
> +{
> +	struct net_device_stats *stats = netdev_priv(dev);
> +	int loop;
> +
> +	DBG("sending skbuff on interface %s\n", dev->name);
> +
> +	stats->tx_packets++;
> +	stats->tx_bytes += skb->len;
> +
> +	/* tx socket reference pointer: Loopback required if not NULL */
> +	loop = *(struct sock **)skb->cb != NULL;


Qdiscs might change skb->cb. Maybe use skb->sk?


> +static int vcan_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
> +{
> +	return -EOPNOTSUPP;
> +}

Not needed.

> +
> +static int vcan_rebuild_header(struct sk_buff *skb)
> +{
> +	DBG("skbuff %p\n", skb);
> +	return 0;
> +}

Also not needed.

> +
> +static int vcan_header(struct sk_buff *skb, struct net_device *dev,
> +		       unsigned short type, void *daddr, void *saddr,
> +		       unsigned int len)
> +{
> +	DBG("skbuff %p, device %p\n", skb, dev);
> +	return 0;
> +}

Also not needed.

> +static struct net_device_stats *vcan_get_stats(struct net_device *dev)
> +{
> +	struct net_device_stats *stats = netdev_priv(dev);
> +
> +	return stats;
> +}

Not needed if you just use dev->stats.

> +static __init int vcan_init_module(void)
> +{
> +	int i, result;
> +
> +	printk(banner);
> +
> +	/* register at least one interface */
> +	if (numdev < 1)
> +		numdev = 1;
> +
> +	printk(KERN_INFO
> +	       "vcan: registering %d virtual CAN interfaces. (loopback %s)\n",
> +	       numdev, loopback ? "enabled" : "disabled");
> +
> +	vcan_devs = kzalloc(numdev * sizeof(struct net_device *), GFP_KERNEL);
> +	if (!vcan_devs) {
> +		printk(KERN_ERR "vcan: Can't allocate vcan devices array!\n");
> +		return -ENOMEM;
> +	}
> +
> +	for (i = 0; i < numdev; i++) {
> +		vcan_devs[i] = alloc_netdev(STATSIZE, "vcan%d", vcan_init);
> +		if (!vcan_devs[i]) {
> +			printk(KERN_ERR "vcan: error allocating net_device\n");
> +			result = -ENOMEM;
> +			goto out;
> +		}
> +
> +		result = register_netdev(vcan_devs[i]);
> +		if (result < 0) {
> +			printk(KERN_ERR
> +			       "vcan: error %d registering interface %s\n",
> +			       result, vcan_devs[i]->name);
> +			free_netdev(vcan_devs[i]);
> +			vcan_devs[i] = NULL;
> +			goto out;
> +
> +		} else {
> +			DBG("successfully registered interface %s\n",
> +			    vcan_devs[i]->name);
> +		}
> +	}
> +
> +	return 0;
> +
> + out:
> +	for (i = 0; i < numdev; i++) {
> +		if (vcan_devs[i]) {
> +			unregister_netdev(vcan_devs[i]);
> +			free_netdev(vcan_devs[i]);
> +		}
> +	}
> +
> +	kfree(vcan_devs);
> +
> +	return result;
> +}


Looks quite large for such a simple task. Should get a lot
simpler by switching to the rtnetlink API.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Patrick McHardy wrote:
> I have a set of patches coming up that introduce a rtnetlink API
> for adding/modifying/deleting software network devices. I would
> prefer if you could switch this driver over instead of doing the
> "create N devices during loading" that many current drivers do,
> leaving you with 20 unused devices after boot.
>   

Hi Patrick,

next Friday? Too late ;-)

Ok, your approach is indeed an interesting idea and we would look on it,
as we also not interested in creating unused devices and do any double
work.

> And it allows you have both loopback and non-loopback devices
> in case that would be useful.
>
> (..)
> Qdiscs might change skb->cb. Maybe use skb->sk?
>
>
>   

The loopback functionality in CAN is a bit tricky (maybe you can take a
look into the Documentation patch [7/7] at chapter 3.2 and 4.1.4).

The problem is, that we need a per socket(!) option that enables the
loopback for the sent CAN-Frames or not, so the information about
loopback a skb content or not is contained inside the skb sent down to
the CAN netdevice. If the CAN networkdevice is not capable to perform a
loopback itself (see dev->flags, chapter 6) the CAN core has to do the
loopback as a fallback.

The use of skb->cb is also needed in the receive path to recognize and
trash loopback'ed CAN-frames inside the *originating* socket (see
chapter 4.1.4).

Please consider the referenced documentation and give me a feedback, if
you have a better idea how to deal with variable loopbacks on driver
level (with is vital for CAN).

Thanks for your feedback,
Oliver

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Oliver Hartkopp wrote:
> Patrick McHardy wrote:
> 
>>I have a set of patches coming up that introduce a rtnetlink API
>>for adding/modifying/deleting software network devices. I would
>>prefer if you could switch this driver over instead of doing the
>>"create N devices during loading" that many current drivers do,
>>leaving you with 20 unused devices after boot.
>>  
> 
> 
> Hi Patrick,
> 
> next Friday? Too late ;-)


This friday :)

> Ok, your approach is indeed an interesting idea and we would look on it,
> as we also not interested in creating unused devices and do any double
> work.


Thanks.

>>(..)
>>Qdiscs might change skb->cb. Maybe use skb->sk?
>>
> 
> The loopback functionality in CAN is a bit tricky (maybe you can take a
> look into the Documentation patch [7/7] at chapter 3.2 and 4.1.4).
> 
> The problem is, that we need a per socket(!) option that enables the
> loopback for the sent CAN-Frames or not, so the information about
> loopback a skb content or not is contained inside the skb sent down to
> the CAN netdevice. If the CAN networkdevice is not capable to perform a
> loopback itself (see dev->flags, chapter 6) the CAN core has to do the
> loopback as a fallback.


skb->sk should work fine for a per socket option. In fact the
CAN core patch simply sets skb->cb to skb->sk.

> The use of skb->cb is also needed in the receive path to recognize and
> trash loopback'ed CAN-frames inside the *originating* socket (see
> chapter 4.1.4).


skb->sk should work here as well since you detect these frames
before queueing to the receiving socket.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Patrick McHardy wrote:
>
>>> (..)
>>> Qdiscs might change skb->cb. Maybe use skb->sk?
>>>
>>>       
>> The loopback functionality in CAN is a bit tricky (maybe you can take a
>> look into the Documentation patch [7/7] at chapter 3.2 and 4.1.4).
>>
>> The problem is, that we need a per socket(!) option that enables the
>> loopback for the sent CAN-Frames or not, so the information about
>> loopback a skb content or not is contained inside the skb sent down to
>> the CAN netdevice. If the CAN networkdevice is not capable to perform a
>> loopback itself (see dev->flags, chapter 6) the CAN core has to do the
>> loopback as a fallback.
>>     
>
>
> skb->sk should work fine for a per socket option. In fact the
> CAN core patch simply sets skb->cb to skb->sk.
>
>   
>> The use of skb->cb is also needed in the receive path to recognize and
>> trash loopback'ed CAN-frames inside the *originating* socket (see
>> chapter 4.1.4).
>>     
>
>
> skb->sk should work here as well since you detect these frames
> before queueing to the receiving socket.
>   

Hm - this would indeed be much nicer than using skb->cb.

I think we just had some concerns to use skb->sk for our own
functionality, as it might be used and dereferenced by other layers
between the socket and the network driver ... so setting skb->sk to NULL
(to indicate 'no loopback') smells bad if you don't really know who ever
dereferences skb->sk.

Btw. it's really worth to look at it again. I just had the idea to
access the loopback flag via skb->sk->opt->loopback (argpfl!) on the TX
path and skb->sk on the RX path. This would avoid skb->sk to be set to
NULL but need to have this loopback flag to be implemented in each CAN
socket opt.

I'll discuss this with Urs tomorrow morning, which change would be the
best and also the 'safest' solution here.

Thanks for your contribution!

Oliver

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Oliver Hartkopp wrote:
> Patrick McHardy wrote:
> 
>>skb->sk should work here as well since you detect these frames
>>before queueing to the receiving socket.
>>  
> 
> 
> Hm - this would indeed be much nicer than using skb->cb.
> 
> I think we just had some concerns to use skb->sk for our own
> functionality, as it might be used and dereferenced by other layers
> between the socket and the network driver ... so setting skb->sk to NULL
> (to indicate 'no loopback') smells bad if you don't really know who ever
> dereferences skb->sk.


Indeed, that will break things.

> Btw. it's really worth to look at it again. I just had the idea to
> access the loopback flag via skb->sk->opt->loopback (argpfl!) on the TX
> path and skb->sk on the RX path. This would avoid skb->sk to be set to
> NULL but need to have this loopback flag to be implemented in each CAN
> socket opt.


Yes, thats what I wanted to suggest. You should even be able
to use skb->sk->opt->loopback on the receive path before you
queue the packet to the socket.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Patrick McHardy wrote:
> Oliver Hartkopp wrote:
>   
>> Btw. it's really worth to look at it again. I just had the idea to
>> access the loopback flag via skb->sk->opt->loopback (argpfl!) on the TX
>> path and skb->sk on the RX path. This would avoid skb->sk to be set to
>> NULL but need to have this loopback flag to be implemented in each CAN
>> socket opt.
>>     
>
>
> Yes, thats what I wanted to suggest. You should even be able
> to use skb->sk->opt->loopback on the receive path before you
> queue the packet to the socket.
>   

Using skb->sk->opt->loopback on the receive path is not possible as you
also have to deal with 'real' data received from a 'real' netdevice,
where no sk is bound to the skb. The idea is to check on the rx path ,
if sbk->sk is 'me' and then trash the packet according to my sockopt
settings.

Regards,
Oliver

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Patrick McHardy wrote:
> Urs Thuermann wrote:
>   
>> +	/* tx socket reference pointer: Loopback required if not NULL */
>> +	loop = *(struct sock **)skb->cb != NULL;
>>     
>
>
> Qdiscs might change skb->cb. Maybe use skb->sk?
>
>   

Hi Patrick,

due to current projects Urs and me had only a short time today to
discuss the use of other skbuff-elements to implement the needed
loopback functionality. Urs remembered that the value of skb->sk was not
'stable' in the whole loopback and therefore the use of skb->cb was a
reasonable approach - and it was indeed working. Btw. triggered by your
remark, we're looking for alternatives.

Another thing is, that i would like to know, if Qdiscs would ever touch
skb's containing CAN-frames?!?
The MTU is 16 bytes (sizeof(struct can_frame)) and each skb contains
exact one CAN-frame.
What would a packet scheduler do with these skb's? IMO there is nothing
that could be optimized and linked together like in IPv4 / IPv6 data.

Would therefore skb->cb left unchanged in my skb's? Or is there any flag
that can be set in the skb to keep the packet scheduler's hands off?

Best regards,
Oliver

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Oliver Hartkopp wrote:
> Patrick McHardy wrote:
> 
>>Urs Thuermann wrote:
>>  
>>
>>>+	/* tx socket reference pointer: Loopback required if not NULL */
>>>+	loop = *(struct sock **)skb->cb != NULL;
>>>    
>>
>>
>>Qdiscs might change skb->cb. Maybe use skb->sk?
>>
>>  
> 
> due to current projects Urs and me had only a short time today to
> discuss the use of other skbuff-elements to implement the needed
> loopback functionality. Urs remembered that the value of skb->sk was not
> 'stable' in the whole loopback and therefore the use of skb->cb was a
> reasonable approach - and it was indeed working. Btw. triggered by your
> remark, we're looking for alternatives.


Yes, its working, but only in certain combinations and you're breaking
the rules for skb->cb, making it impossible for other layers to use.
skb->sk is "stable" at the output path, the regular loopback device
orphans the skb in hard_start_xmit. So you can at least use it there.

> Another thing is, that i would like to know, if Qdiscs would ever touch
> skb's containing CAN-frames?!?
> The MTU is 16 bytes (sizeof(struct can_frame)) and each skb contains
> exact one CAN-frame.
> What would a packet scheduler do with these skb's? IMO there is nothing
> that could be optimized and linked together like in IPv4 / IPv6 data.


Qdiscs don't care about the content. If a user attaches one to your
device, it will get used.

> Would therefore skb->cb left unchanged in my skb's? Or is there any flag
> that can be set in the skb to keep the packet scheduler's hands off?


No, and I don't think we want a flag to signal that something is
violating the rules for skb->cb, there are other users of this
besides qdiscs.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Patrick McHardy wrote:
> Oliver Hartkopp wrote:
>   
>> Patrick McHardy wrote:
>>     
>
> Yes, its working, but only in certain combinations and you're breaking
> the rules for skb->cb, making it impossible for other layers to use.
> skb->sk is "stable" at the output path, the regular loopback device
> orphans the skb in hard_start_xmit. So you can at least use it there.
>
>   
>> Would therefore skb->cb left unchanged in my skb's? Or is there any flag
>> that can be set in the skb to keep the packet scheduler's hands off?
>>     
>
>
> No, and I don't think we want a flag to signal that something is
> violating the rules for skb->cb, there are other users of this
> besides qdiscs.
>   

Hm - regarding Patricks and Urs' last mails i just had the idea to put
the sk-reference that's needed for this special
CAN-only-loopback-functionality into the data section of the skb, e.g.
by introducing a new struct can_skb_data:

struct can_skb_data {
    struct can_frame cf;
    sock *txsk;
};

So instead of allocating the space of struct can_frame the alloc_skb()
would allocate the size of struct can_skb_data.
The needed txsk would be stable in any case and could be used like the
currently missused skb->cb. This would also lead to a type proof(!)
implementation.

In raw_rcv() in raw.c there could be a check for the size of struct
can_skb_data first before checking the txsk - this would also guarantee
the backward compatibility for current CAN drivers that allocate only
the size of struct can_frame. For me this looks like a safe and
compatible (Kernel & CAN) solution.

Any objections/comments for this approach?

Best regards,
Oliver

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

The more i was thinking about my own suggested solution the more it
turned out to be ugly for me ...

Summarizing we have two problems to solve:

1. Identify the originating sk to potentially trash my own sent messages.
2. Indicate a requested local loopback to the lower (driver) layer.

Regarding point 1.:
skb->sk is intentionally set to NULL, when ever skb_orphan() or
skb_clone() is invoked to cut the reference to the sk. Performing a
loopback this is a reasonable thing to do as also skb->destructor(skb)
is called in skb_orphan().

Indeed skb->sk is completely unused in the rx path, so we just would
have to 'preserve' skb->sk the way 'up' whenever we make use of
skb_orphan() or skb_clone().

E.g. in af_can.c the deliver() function would be changed like this:

static inline void deliver(struct sk_buff *skb, struct receiver *r)
{
+	struct sock *sk = skb->sk;
	struct sk_buff *clone = skb_clone(skb, GFP_ATOMIC);

	DBG("skbuff %p cloned to %p\n", skb, clone);
	if (clone) {
+		clone->sk = sk;
		r->func(clone, r->data);
		r->matches++;
	}
}

So there is a proper way to make the originating sk avaliable when the
skb reaches the receiving socket.

Regarding point 2.:
To indicate an outgoing skb to be looped back it would just be enough to
set skb->tstamp at skb creation time. This would be similar to set the
timestamp at netdev receive time. skb->tstamp is also completely unused
in the tx path. In the case of local loopback setting the timestamp at
this creation stage is not even a wrong semantic behaviour.

Assuming some clarifying comments in the source code this looks like a
simple to use and clearly arranged implementation to me. I'll make a
test implementation tomorrow to see how if it smells as good as i
expected ;-)

Best  regards,
Oliver


Oliver Hartkopp wrote:
> Patrick McHardy wrote:
>   
>> Oliver Hartkopp wrote:
>>   
>>     
>>> Patrick McHardy wrote:
>>>     
>>>       
>> Yes, its working, but only in certain combinations and you're breaking
>> the rules for skb->cb, making it impossible for other layers to use.
>> skb->sk is "stable" at the output path, the regular loopback device
>> orphans the skb in hard_start_xmit. So you can at least use it there.
>>
>>   
>>     
>>> Would therefore skb->cb left unchanged in my skb's? Or is there any flag
>>> that can be set in the skb to keep the packet scheduler's hands off?
>>>     
>>>       
>> No, and I don't think we want a flag to signal that something is
>> violating the rules for skb->cb, there are other users of this
>> besides qdiscs.
>>   
>>     
>
> Hm - regarding Patricks and Urs' last mails i just had the idea to put
> the sk-reference that's needed for this special
> CAN-only-loopback-functionality into the data section of the skb, e.g.
> by introducing a new struct can_skb_data:
>
> struct can_skb_data {
>     struct can_frame cf;
>     sock *txsk;
> };
>
> So instead of allocating the space of struct can_frame the alloc_skb()
> would allocate the size of struct can_skb_data.
> The needed txsk would be stable in any case and could be used like the
> currently missused skb->cb. This would also lead to a type proof(!)
> implementation.
>
> In raw_rcv() in raw.c there could be a check for the size of struct
> can_skb_data first before checking the txsk - this would also guarantee
> the backward compatibility for current CAN drivers that allocate only
> the size of struct can_frame. For me this looks like a safe and
> compatible (Kernel & CAN) solution.
>
> Any objections/comments for this approach?
>
> Best regards,
> Oliver
>
>
> -
> 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
>
>   

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Oliver Hartkopp wrote:
> The more i was thinking about my own suggested solution the more it
> turned out to be ugly for me ...
>
> Summarizing we have two problems to solve:
>
> 1. Identify the originating sk to potentially trash my own sent messages.
> 2. Indicate a requested local loopback to the lower (driver) layer.
>
> Regarding point 1.:
> skb->sk is intentionally set to NULL, when ever skb_orphan() or
> skb_clone() is invoked to cut the reference to the sk. Performing a
> loopback this is a reasonable thing to do as also skb->destructor(skb)
> is called in skb_orphan().
>
> Indeed skb->sk is completely unused in the rx path, so we just would
> have to 'preserve' skb->sk the way 'up' whenever we make use of
> skb_orphan() or skb_clone().
>
> E.g. in af_can.c the deliver() function would be changed like this: 

(..)

Now it's done:

1. The needed skb->sk is preserved for the rx path (the way 'up').
2. The loopback indication is done by using the unused skb->protocol in
the tx path.
3. skb->cb is now unused (which was a breaking of rules as remarked by
Patrick)

And finally: It's working fine and appears nice :-)

Please have a look on the sparse changes i would like to commit on the
project SVN.
If there are no objections from your side these (and the other remarked)
changes will go into the next patch series for PF_CAN.

Special thanks to Patrick for the important feedback on the skb->cb usage!!

Best regards,
Oliver

(please excuse the wrong white spaces ...)

Index: net/can/af_can.c
===================================================================
--- net/can/af_can.c    (revision 324)
+++ net/can/af_can.c    (working copy)
@@ -257,7 +257,6 @@
  */
 int can_send(struct sk_buff *skb, int loop)
 {
-    struct sock **tx_sk = (struct sock **)skb->cb;
     int err;
 
     if (skb->dev->type != ARPHRD_CAN) {
@@ -268,27 +267,34 @@
     if (loop) {
         /* local loopback of sent CAN frames (default) */
 
-        /* indication for the CAN driver: do loopback */
-        *tx_sk = skb->sk;
+        /*
+         * skb->protocol is unused in the tx path. We use it
+         * to indicate to the CAN driver 'do loopback!' by
+         * setting skb->protocol to an appropriate value.
+         */
+        skb->protocol = htons(ETH_P_CAN);
 
         /*
-         * The reference to the originating sock may be also required
+         * The reference to the originating sock may be required
          * by the receiving socket to indicate (and ignore) his own
-         * sent data. Example: can_raw sockopt CAN_RAW_RECV_OWN_MSGS
+         * sent data. Example: can_raw sockopt CAN_RAW_RECV_OWN_MSGS.
+         * Therefore we have to ensure that skb->sk remains the
+         * reference to the originating sock by restoring skb->sk
+         * after each skb_clone() or skb_orphan() usage.
+         * skb->sk is usually unused and unset in the rx path.
          */
 
         /* interface not capabable to do the loopback itself? */
         if (!(skb->dev->flags & IFF_LOOPBACK)) {
+            struct sock *srcsk = skb->sk;
             struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC);
 
             /* perform the local loopback here */
             newskb->protocol  = htons(ETH_P_CAN);
             newskb->ip_summed = CHECKSUM_UNNECESSARY;
+            newskb->sk = srcsk;
             netif_rx(newskb);
         }
-    } else {
-        /* indication for the CAN driver: no loopback required */
-        *tx_sk = NULL;
     }
 
     if (!(skb->dev->flags & IFF_UP))
@@ -581,10 +587,12 @@
 
 static inline void deliver(struct sk_buff *skb, struct receiver *r)
 {
+    struct sock *srcsk = skb->sk;
     struct sk_buff *clone = skb_clone(skb, GFP_ATOMIC);
 
     DBG("skbuff %p cloned to %p\n", skb, clone);
     if (clone) {
+        clone->sk = srcsk;
         r->func(clone, r->data);
         r->matches++;
     }
Index: net/can/raw.c
===================================================================
--- net/can/raw.c    (revision 324)
+++ net/can/raw.c    (working copy)
@@ -154,7 +154,7 @@
 
     if (!ro->recv_own_msgs) {
         /* check the received tx sock reference */
-        if (*(struct sock **)skb->cb == sk) {
+        if (skb->sk == sk) {
             DBG("trashed own tx msg\n");
             kfree_skb(skb);
             return;
Index: drivers/net/can/vcan.c
===================================================================
--- drivers/net/can/vcan.c    (revision 324)
+++ drivers/net/can/vcan.c    (working copy)
@@ -149,8 +149,8 @@
     stats->tx_packets++;
     stats->tx_bytes += skb->len;
 
-    /* tx socket reference pointer: Loopback required if not NULL */
-    loop = *(struct sock **)skb->cb != NULL;
+    /* indication for CAN netdevice drivers that loopback is required */
+    loop = (skb->protocol == htons(ETH_P_CAN));
 
     if (!loopback) {
         /* no loopback handling available inside this driver */
@@ -170,6 +170,8 @@
     /* perform standard loopback handling for CAN network interfaces */
 
     if (loop) {
+        struct sock *srcsk = skb->sk;
+
         if (atomic_read(&skb->users) != 1) {
             struct sk_buff *old_skb = skb;
 
@@ -183,6 +185,8 @@
         } else
             skb_orphan(skb);
 
+        skb->sk = srcsk;
+
         /* receive with packet counting */
         vcan_rx(skb, dev);
     } else {

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Oliver Hartkopp wrote:
> 1. The needed skb->sk is preserved for the rx path (the way 'up').


I was thinking about this, don't CAN frames include the identity
of the sender? That would be the easiest way to determine whether
the frame needs to be delivered.

> 2. The loopback indication is done by using the unused skb->protocol in
> the tx path.


Actually its not unused, it needs to be set on TX frames once the
packet leaves the protocol specific code. Its used for example by
packet sockets (sk_run_filter), qdisc classification, neighbour
resolution, gso segmentation, ...

I don't get why you can't directly check the socket option on the
TX path.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

Patrick McHardy <kaber@trash.net> writes:

> I was thinking about this, don't CAN frames include the identity
> of the sender? That would be the easiest way to determine whether
> the frame needs to be delivered.

No, CAN is quite a broken networking technology (at least in my view,
coming from tcp/ip).  There is no station addresses and therefore no
sender or receiver addresses.  Everything is broadcast.

> Actually its not unused, it needs to be set on TX frames once the
> packet leaves the protocol specific code.

Oops, yes, this is something still missing in our code.  Needs to be
fixed.

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

urs

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Urs Thuermann wrote:
> Patrick McHardy <kaber@trash.net> 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.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

Oliver Hartkopp <socketcan@hartkopp.net> writes:

> 2. The loopback indication is done by using the unused skb->protocol in
> the tx path.

I don't think we should (mis-)use skb->protocol as a loopback flag.
As the name says, it's the protocol number and not a flag whether
loopback is to be done by the driver.  Even if it's not used otherwise
in tx path (haven't checked this), in my experience it is asking for
future trouble to use variables other than for it's intended purpose.

IMO it would be better to skb->pkt_type.  This is used to indicate
packet type to rcv functions registered by dev_add_pack().  It is set
by netdevice drivers to PACKET_{MULTICAST,BROADCAST,HOST,OTHER} for
received packets.  In the send path it is set to PACKET_OUTGOING on
the copy of the skbuff that is delivered to the sockets registered on
ptype_all (typically packet sockets from tcpdump or other sniffers).
AFAICS, pkt_type is not used otherwise in the send path.

We could set skb->pkt_type = PACKET_LOOPBACK to flag to the CAN
netdevice driver whether to loop back the packet.

Any objections?

urs

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Urs Thuermann wrote:
> Oliver Hartkopp <socketcan@hartkopp.net> writes:
>
>   
>> 2. The loopback indication is done by using the unused skb->protocol in
>> the tx path.
>>     
>
> I don't think we should (mis-)use skb->protocol as a loopback flag.
>   

Yep! After reading the comments from Patrick and Urs i definitely agree
to their concerns.

> IMO it would be better to skb->pkt_type.  This is used to indicate
> packet type to rcv functions registered by dev_add_pack().  It is set
> by netdevice drivers to PACKET_{MULTICAST,BROADCAST,HOST,OTHER} for
> received packets.  In the send path it is set to PACKET_OUTGOING on
> the copy of the skbuff that is delivered to the sockets registered on
> ptype_all (typically packet sockets from tcpdump or other sniffers).
> AFAICS, pkt_type is not used otherwise in the send path.
>
> We could set skb->pkt_type = PACKET_LOOPBACK to flag to the CAN
> netdevice driver whether to loop back the packet.
>   

I think, it goes into the right direction to use skb->pkt_type. The flag
should really be somewhere inside the skb as all back references into
the sk would become sticky in the implementation.

But regarding the use of skb->pkt_type i would suggest to take a closer
look on the definitions in include/linux/if_packet.h and how the
pkt_type is to be used inside the kernel. In my opinion we should use ...

* TX-Path:
PACKET_OTHERHOST: send the CAN frame without loopback
PACKET_BROADCAST : send the CAN frame with loopback (aka local broadcast)

See an example of this approach in drivers/net/arcnet/rfc1051.c :
http://www.linux-m32r.org/lxr/http/source/drivers/net/arcnet/rfc1051.c?a=i386#L99

* RX-Path:
PACKET_HOST : just an incoming CAN frame for this host

Any comments? ACKs?

Best regards,
Oliver

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Oliver Hartkopp wrote:
> I think, it goes into the right direction to use skb->pkt_type. The flag
> should really be somewhere inside the skb as all back references into
> the sk would become sticky in the implementation.
>
> But regarding the use of skb->pkt_type i would suggest to take a closer
> look on the definitions in include/linux/if_packet.h and how the
> pkt_type is to be used inside the kernel. In my opinion we should use ...
>
> * TX-Path:
> PACKET_OTHERHOST: send the CAN frame without loopback
> PACKET_BROADCAST : send the CAN frame with loopback (aka local broadcast)
>
> See an example of this approach in drivers/net/arcnet/rfc1051.c :
> http://www.linux-m32r.org/lxr/http/source/drivers/net/arcnet/rfc1051.c?a=i386#L99
>
> * RX-Path:
> PACKET_HOST : just an incoming CAN frame for this host
>
> Any comments? ACKs?
>
> Best regards,
> Oliver
>
>
>   

The updated changes would look like this. Of course it has been tested
and is working fine :-)

Regards,
Oliver

Index: net/can/af_can.c
===================================================================
--- net/can/af_can.c    (revision 325)
+++ net/can/af_can.c    (working copy)
@@ -257,7 +257,6 @@
  */
 int can_send(struct sk_buff *skb, int loop)
 {
-    struct sock **tx_sk = (struct sock **)skb->cb;
     int err;
 
     if (skb->dev->type != ARPHRD_CAN) {
@@ -265,30 +264,43 @@
         return -EPERM;
     }
 
+    skb->protocol = htons(ETH_P_CAN);
+
     if (loop) {
         /* local loopback of sent CAN frames (default) */
 
-        /* indication for the CAN driver: do loopback */
-        *tx_sk = skb->sk;
+        /*
+         * This packet is not only sent on the CAN bus but
+         * also broadcasted to local subscribers on this host.
+         */
+        skb->pkt_type = PACKET_BROADCAST;
 
         /*
-         * The reference to the originating sock may be also required
+         * The reference to the originating sock may be required
          * by the receiving socket to indicate (and ignore) his own
-         * sent data. Example: can_raw sockopt CAN_RAW_RECV_OWN_MSGS
+         * sent data. Example: can_raw sockopt CAN_RAW_RECV_OWN_MSGS.
+         * Therefore we have to ensure that skb->sk remains the
+         * reference to the originating sock by restoring skb->sk
+         * after each skb_clone() or skb_orphan() usage.
+         * skb->sk is usually unused and unset in the rx path.
          */
 
         /* interface not capabable to do the loopback itself? */
         if (!(skb->dev->flags & IFF_LOOPBACK)) {
+            struct sock *srcsk = skb->sk;
             struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC);
 
             /* perform the local loopback here */
-            newskb->protocol  = htons(ETH_P_CAN);
             newskb->ip_summed = CHECKSUM_UNNECESSARY;
+            newskb->sk = srcsk;
             netif_rx(newskb);
         }
     } else {
-        /* indication for the CAN driver: no loopback required */
-        *tx_sk = NULL;
+        /*
+         * Indication for the CAN driver: No loopback required!
+         * This packet is only transmitted to the CAN bus.
+         */
+        skb->pkt_type = PACKET_OTHERHOST;
     }
 
     if (!(skb->dev->flags & IFF_UP))
@@ -581,10 +593,12 @@
 
 static inline void deliver(struct sk_buff *skb, struct receiver *r)
 {
+    struct sock *srcsk = skb->sk;
     struct sk_buff *clone = skb_clone(skb, GFP_ATOMIC);
 
     DBG("skbuff %p cloned to %p\n", skb, clone);
     if (clone) {
+        clone->sk = srcsk;
         r->func(clone, r->data);
         r->matches++;
     }
Index: net/can/raw.c
===================================================================
--- net/can/raw.c    (revision 325)
+++ net/can/raw.c    (working copy)
@@ -154,7 +154,7 @@
 
     if (!ro->recv_own_msgs) {
         /* check the received tx sock reference */
-        if (*(struct sock **)skb->cb == sk) {
+        if (skb->sk == sk) {
             DBG("trashed own tx msg\n");
             kfree_skb(skb);
             return;
Index: drivers/net/can/vcan.c
===================================================================
--- drivers/net/can/vcan.c    (revision 325)
+++ drivers/net/can/vcan.c    (working copy)
@@ -133,6 +133,7 @@
     skb->protocol  = htons(ETH_P_CAN);
     skb->dev       = dev;
     skb->ip_summed = CHECKSUM_UNNECESSARY;
+    skb->pkt_type  = PACKET_HOST;
 
     DBG("received skbuff on interface %d\n", dev->ifindex);
 
@@ -149,8 +150,8 @@
     stats->tx_packets++;
     stats->tx_bytes += skb->len;
 
-    /* tx socket reference pointer: Loopback required if not NULL */
-    loop = *(struct sock **)skb->cb != NULL;
+    /* indication for CAN netdevice drivers that loopback is required */
+    loop = (skb->pkt_type == PACKET_BROADCAST);
 
     if (!loopback) {
         /* no loopback handling available inside this driver */
@@ -170,6 +171,8 @@
     /* perform standard loopback handling for CAN network interfaces */
 
     if (loop) {
+        struct sock *srcsk = skb->sk;
+
         if (atomic_read(&skb->users) != 1) {
             struct sk_buff *old_skb = skb;
 
@@ -183,6 +186,8 @@
         } else
             skb_orphan(skb);
 
+        skb->sk = srcsk;
+
         /* receive with packet counting */
         vcan_rx(skb, dev);
     } else {

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

Patrick McHardy <kaber@trash.net> writes:

> I have a set of patches coming up that introduce a rtnetlink API
> for adding/modifying/deleting software network devices. I would
> prefer if you could switch this driver over instead of doing the
> "create N devices during loading" that many current drivers do,
> leaving you with 20 unused devices after boot.
> 
> > +static int loopback = 0; /* vcan default: no loopback, just free the skb */
> > +module_param(loopback, int, S_IRUGO);
> > +MODULE_PARM_DESC(loopback, "Loop back sent frames. vcan default: 0 (Off)");
> 
> 
> And it allows you have both loopback and non-loopback devices
> in case that would be useful.

That sounds very promising.  I also was unhappy with the fixed number
of vcan devices at module load time and have thought about ioctl's to
add/delete devices and to change the loopback flag.  A more general
approach like the one you seem to be working on is preferable of
course.

> Qdiscs might change skb->cb. Maybe use skb->sk?

When we decided to use skb->cb it seemed the only possible option.
We need a field that we can set to zero to indicate we don't want the
driver to loop back the packet and the value in that field must
survive the path

        can_send()
        dev_queue_xmit()
        ...
        dev->hard_start_xmit()
        
        netif_rx()
        can_rcv()

I think I misread the comment

 *      @cb: Control buffer. Free for use by every layer. Put private vars here

to mean I can use it for this purpose and since it worked as intended
we felt ok with this.  Now I see, it states exactly the opposite that
I can't count on the value being preserved across layers.

skb->sk can't be used since we shouldn't set it to zero before
dev_queue_xmit() as Oliver already pointed out.  IIRC, skb->sk
couldn't also be used in rx half of that path, since it was set to
null somewhere in netif_rx() but now, reading the src, I can't see
where this would happen.  Maybe this has changed or my memory has some
bit errors.  I'll look at it again.  Even if it turns out skb->sk can
be used in rx path, the need remains to pass down a flag from
can_send() to dev->hard_start_xmit() indicating whether to loop back
or not.

> > +static int vcan_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
> 
> Not needed.
> 
> > +static int vcan_rebuild_header(struct sk_buff *skb)
> 
> Also not needed.
> 
> > +static int vcan_header(struct sk_buff *skb, struct net_device *dev,
> 
> Also not needed.

Yep.  These are some remnants from when I was experimenting to see
when these functions are called and with what args.  We will remove
this.  Thanks for pointing this out.

> > +static struct net_device_stats *vcan_get_stats(struct net_device *dev)
> > +{
> > +	struct net_device_stats *stats = netdev_priv(dev);
> > +
> > +	return stats;
> > +}
> 
> Not needed if you just use dev->stats.

OK, this was added *very* recently in some 2.6.22-{pre,rc} version and
I haven't noticed before.  We'll use that.

> > +static __init int vcan_init_module(void)
> 
> Looks quite large for such a simple task. Should get a lot
> simpler by switching to the rtnetlink API.

That would be nice.

urs

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Patrick McHardy]

Urs Thuermann wrote:
> Patrick McHardy <kaber@trash.net> writes:
> 
>>And it allows you have both loopback and non-loopback devices
>>in case that would be useful.
> 
> 
> That sounds very promising.  I also was unhappy with the fixed number
> of vcan devices at module load time and have thought about ioctl's to
> add/delete devices and to change the loopback flag.  A more general
> approach like the one you seem to be working on is preferable of
> course.


I got a bit delayed, but I hope to have the patches in postable state
tommorrow.

>>Qdiscs might change skb->cb. Maybe use skb->sk?
> 
> 
> When we decided to use skb->cb it seemed the only possible option.
> We need a field that we can set to zero to indicate we don't want the
> driver to loop back the packet and the value in that field must
> survive the path
> 
>         can_send()
>         dev_queue_xmit()
>         ...
>         dev->hard_start_xmit()
>         
>         netif_rx()
>         can_rcv()
> 
> I think I misread the comment
> 
>  *      @cb: Control buffer. Free for use by every layer. Put private vars here
> 
> to mean I can use it for this purpose and since it worked as intended
> we felt ok with this.  Now I see, it states exactly the opposite that
> I can't count on the value being preserved across layers.


Yes, that comment is a bit misleading.

> skb->sk can't be used since we shouldn't set it to zero before
> dev_queue_xmit() as Oliver already pointed out.  IIRC, skb->sk
> couldn't also be used in rx half of that path, since it was set to
> null somewhere in netif_rx() but now, reading the src, I can't see
> where this would happen.  Maybe this has changed or my memory has some
> bit errors.  I'll look at it again.  Even if it turns out skb->sk can
> be used in rx path, the need remains to pass down a flag from
> can_send() to dev->hard_start_xmit() indicating whether to loop back
> or not.


That flag is a socket flag acording to Oliver, so you can use the flag
itself. You could keep skb->sk for the RX path (don't call skb_orphan
in your hard_start_xmit function), if that doesn't work worst case would
be to use a flag in the skb (we still have 2 unused bits) until you've
figured out a better way.

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Stephen Hemminger]

In addition to Patrick's comments.

> +
> +static void vcan_init(struct net_device *dev)
> +{
> +	DBG("dev %s\n", dev->name);
> +
> +	ether_setup(dev);

Do really want to do this?
  - you set different flags/type after this.
  - do you really want change_mtu to call eth_change_mtu
Better off to just copy what you want out of ether_setup if
your device is not really an ether device.


> +	memset(dev->priv, 0, STATSIZE);

Unneeded alloc_netdev always zero's

> +
> +	dev->type              = ARPHRD_CAN;
> +	dev->mtu               = sizeof(struct can_frame);
> +	dev->flags             = IFF_NOARP;
> +
> +	/* set flags according to driver capabilities */
> +	if (loopback)
> +		dev->flags |= IFF_LOOPBACK;
> +
> +	dev->open              = vcan_open;
> +	dev->stop              = vcan_stop;
> +	dev->set_config        = NULL;
unneeded

> +	dev->hard_start_xmit   = vcan_tx;
> +	dev->do_ioctl          = vcan_ioctl;
> +	dev->get_stats         = vcan_get_stats;
> +	dev->hard_header       = vcan_header;
> +	dev->rebuild_header    = vcan_rebuild_header;
> +	dev->hard_header_cache = NULL;
unneeded

> +	SET_MODULE_OWNER(dev);
> +}
> +
> +static __init int vcan_init_module(void)
> +{
> +	int i, result;
> +
> +	printk(banner);
> +
> +	/* register at least one interface */
> +	if (numdev < 1)
> +		numdev = 1;
> +
> +	printk(KERN_INFO
> +	       "vcan: registering %d virtual CAN interfaces. (loopback %s)\n",
> +	       numdev, loopback ? "enabled" : "disabled");
> +
> +	vcan_devs = kzalloc(numdev * sizeof(struct net_device *), GFP_KERNEL);
kcalloc() instead?

> +	if (!vcan_devs) {
> +		printk(KERN_ERR "vcan: Can't allocate vcan devices array!\n");
> +		return -ENOMEM;
> +	}
> +
> +	for (i = 0; i < numdev; i++) {
> +		vcan_devs[i] = alloc_netdev(STATSIZE, "vcan%d", vcan_init);
> +		if (!vcan_devs[i]) {
> +			printk(KERN_ERR "vcan: error allocating net_device\n");
> +			result = -ENOMEM;
> +			goto out;
> +		}
> +
> +		result = register_netdev(vcan_devs[i]);
> +		if (result < 0) {
> +			printk(KERN_ERR
> +			       "vcan: error %d registering interface %s\n",
> +			       result, vcan_devs[i]->name);
> +			free_netdev(vcan_devs[i]);
> +			vcan_devs[i] = NULL;
> +			goto out;
> +
> +		} else {
> +			DBG("successfully registered interface %s\n",
> +			    vcan_devs[i]->name);
> +		}
> +	}
> +
> +	return 0;
> +
> + out:
> +	for (i = 0; i < numdev; i++) {
> +		if (vcan_devs[i]) {
> +			unregister_netdev(vcan_devs[i]);
> +			free_netdev(vcan_devs[i]);
> +		}
> +	}
> +
> +	kfree(vcan_devs);
> +
> +	return result;
> +}
> +
> +static __exit void vcan_cleanup_module(void)
> +{
> +	int i;
> +
> +	for (i = 0; i < numdev; i++) {
> +		if (vcan_devs[i]) {
> +			unregister_netdev(vcan_devs[i]);
> +			free_netdev(vcan_devs[i]);
> +		}
> +	}
> +
> +	kfree(vcan_devs);
> +}
> +
> +module_init(vcan_init_module);
> +module_exit(vcan_cleanup_module);
> Index: linux-2.6.22-rc3/net/can/Kconfig
> ===================================================================
> --- linux-2.6.22-rc3.orig/net/can/Kconfig	2007-05-30 14:58:03.000000000 +0200
> +++ linux-2.6.22-rc3/net/can/Kconfig	2007-05-30 14:58:05.000000000 +0200
> @@ -77,3 +77,6 @@
>  	  Say Y here if you want the CAN core to produce a bunch of debug
>  	  messages to the system log.  Select this if you are having a
>  	  problem with CAN support and want to see more of what is going on.
> +
> +
> +source "drivers/net/can/Kconfig"
> 
> --
> -
> 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


-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Stephen Hemminger wrote:
> In addition to Patrick's comments.
>
>   
>> +
>> +static void vcan_init(struct net_device *dev)
>> +{
>> +	DBG("dev %s\n", dev->name);
>> +
>> +	ether_setup(dev);
>>     
>
> Do really want to do this?
>   - you set different flags/type after this.
>   - do you really want change_mtu to call eth_change_mtu
> Better off to just copy what you want out of ether_setup if
> your device is not really an ether device.
>   

Yep! That's reasonable. Thanks.


>> +
>> +	dev->type              = ARPHRD_CAN;
>> +	dev->mtu               = sizeof(struct can_frame);
>> +	dev->flags             = IFF_NOARP;
>> +
>> +	/* set flags according to driver capabilities */
>> +	if (loopback)
>> +		dev->flags |= IFF_LOOPBACK;
>> +
>> +	dev->open              = vcan_open;
>> +	dev->stop              = vcan_stop;
>> +	dev->set_config        = NULL;
>>     
> unneeded
>
>   
>> +	dev->hard_start_xmit   = vcan_tx;
>> +	dev->do_ioctl          = vcan_ioctl;
>> +	dev->get_stats         = vcan_get_stats;
>> +	dev->hard_header       = vcan_header;
>> +	dev->rebuild_header    = vcan_rebuild_header;
>> +	dev->hard_header_cache = NULL;
>>     
> unneeded
>
>   

Does 'unneeded' belong to always the last line of the quoted code snippet?

Regards,
Oliver

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Stephen Hemminger]

On Wed, 30 May 2007 20:57:33 +0200
Oliver Hartkopp <oliver@hartkopp.net> wrote:

>
> 
> Does 'unneeded' belong to always the last line of the quoted code snippet?
> 

They are all places where you assign zero (or NULL) to something that is
already initialized to zero by alloc_netdev.

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

[Oliver Hartkopp]

Stephen Hemminger wrote:
> On Wed, 30 May 2007 20:57:33 +0200
> Oliver Hartkopp <oliver@hartkopp.net> wrote:
>
>   
>> Does 'unneeded' belong to always the last line of the quoted code snippet?
>>
>>     
>
> They are all places where you assign zero (or NULL) to something that is
> already initialized to zero by alloc_netdev.
>
>   

ACK! Will be removed.

Thanks,
Oliver

[patch 0/7] CAN: Add new PF_CAN protocol family

[Urs Thuermann]

This patch series applies against linux-2.6.22-rc1-git4.  It adds a new
protocol family to Linux for communication on the CAN (Controller Area
Network) using the socket API.

The current implementation supports two protocols in the family, a raw
protocol for sending and receiving raw CAN frames, and a broadcast
manager protocol, which effeciently handles periodically sent
broadcast messages, which are typical in CAN environments.

There is also a virtual CAN network driver which only loops back sent
CAN frames.  Drivers for real CAN hardware are also being worked on
and are nearly complete.  These will be released later, or you can find
them in the subversion repository at
http://svn.berlios.de/svnroot/repos/socketcan.

Additional information about the concepts of the CAN protocol family
can be found in the file Documentation/networking/can.txt, added by
patch 7/7.

Userspace tools (can-utils) and test suites for the different CAN
protocols can also be found in the subversion repository.
--

[patch 5/7] CAN: Add virtual CAN netdevice driver

[Urs Thuermann]

[-- Attachment #1: 05-can-vcan-driver.diff --]
[-- Type: text/plain, Size: 11862 bytes --]

This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.

Signed-Off-By: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-Off-By: Urs Thuermann <urs.thuermann@volkswagen.de>

---
 drivers/net/Makefile     |    1 
 drivers/net/can/Kconfig  |   25 +++
 drivers/net/can/Makefile |    5 
 drivers/net/can/vcan.c   |  308 +++++++++++++++++++++++++++++++++++++++++++++++
 net/can/Kconfig          |    3 
 5 files changed, 342 insertions(+)

Index: linux-2.6.22-rc1-git4/drivers/net/Makefile
===================================================================
--- linux-2.6.22-rc1-git4.orig/drivers/net/Makefile	2007-05-16 09:44:54.000000000 +0200
+++ linux-2.6.22-rc1-git4/drivers/net/Makefile	2007-05-16 09:45:00.000000000 +0200
@@ -8,6 +8,7 @@
 obj-$(CONFIG_CHELSIO_T1) += chelsio/
 obj-$(CONFIG_CHELSIO_T3) += cxgb3/
 obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
 obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_ATL1) += atl1/
 obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: linux-2.6.22-rc1-git4/drivers/net/can/Kconfig
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.22-rc1-git4/drivers/net/can/Kconfig	2007-05-16 09:45:00.000000000 +0200
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+	depends on CAN
+
+config CAN_VCAN
+	tristate "Virtual Local CAN Interface (vcan)"
+ 	depends on CAN
+	default N
+ 	---help---
+	  Similar to the network loopback devices, vcan offers a
+	  virtual local CAN interface.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called vcan.
+
+config CAN_DEBUG_DEVICES
+	bool "CAN devices debugging messages"
+	depends on CAN
+	default N
+	---help---
+	  Say Y here if you want the CAN device drivers to produce a bunch of
+	  debug messages to the system log.  Select this if you are having
+	  a problem with CAN support and want to see more of what is going
+	  on.
+
+endmenu
Index: linux-2.6.22-rc1-git4/drivers/net/can/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.22-rc1-git4/drivers/net/can/Makefile	2007-05-16 09:45:00.000000000 +0200
@@ -0,0 +1,5 @@
+#
+#  Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN)		+= vcan.o
Index: linux-2.6.22-rc1-git4/drivers/net/can/vcan.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.22-rc1-git4/drivers/net/can/vcan.c	2007-05-16 09:55:30.000000000 +0200
@@ -0,0 +1,308 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions, the following disclaimer and
+ *    the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2 as distributed in the 'COPYING'
+ * file from the main directory of the linux kernel source.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <socketcan-users@lists.berlios.de>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/if_arp.h>
+#include <linux/if_ether.h>
+#include <linux/can.h>
+
+static __initdata const char banner[] =
+	KERN_INFO "vcan: Virtual CAN interface driver\n";
+
+MODULE_DESCRIPTION("virtual CAN interface");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Urs Thuermann <urs.thuermann@volkswagen.de>");
+
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+static int debug = 0;
+module_param(debug, int, S_IRUGO);
+#endif
+
+/* To be moved to linux/can/dev.h */
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+#define DBG(args...)       (debug & 1 ? \
+			       (printk(KERN_DEBUG "vcan %s: ", __func__), \
+				printk(args)) : 0)
+#else
+#define DBG(args...)
+#endif
+
+#define STATSIZE sizeof(struct net_device_stats)
+
+static int numdev = 4; /* default number of virtual CAN interfaces */
+module_param(numdev, int, S_IRUGO);
+MODULE_PARM_DESC(numdev, "Number of virtual CAN devices");
+
+/*
+ * CAN network devices *should* support a local loopback functionality
+ * (see Documentation/networking/can.txt). To test the handling of CAN
+ * interfaces that do not support the loopback both driver types are
+ * implemented inside this vcan driver. In the case that the driver does
+ * not support the loopback the IFF_LOOPBACK remains clear in dev->flags.
+ * This causes the PF_CAN core to perform the loopback as a fallback solution.
+ */
+
+static int loopback = 0; /* vcan default: no loopback, just free the skb */
+module_param(loopback, int, S_IRUGO);
+MODULE_PARM_DESC(loopback, "Loop back sent frames. vcan default: 0 (Off)");
+
+static struct net_device **vcan_devs; /* root pointer to netdevice structs */
+
+static int vcan_open(struct net_device *dev)
+{
+	DBG("%s: interface up\n", dev->name);
+
+	netif_start_queue(dev);
+	return 0;
+}
+
+static int vcan_stop(struct net_device *dev)
+{
+	DBG("%s: interface down\n", dev->name);
+
+	netif_stop_queue(dev);
+	return 0;
+}
+
+static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = netdev_priv(dev);
+
+	stats->rx_packets++;
+	stats->rx_bytes += skb->len;
+
+	skb->protocol  = htons(ETH_P_CAN);
+	skb->dev       = dev;
+	skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	DBG("received skbuff on interface %d\n", dev->ifindex);
+
+	netif_rx(skb);
+}
+
+static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = netdev_priv(dev);
+	int loop;
+
+	DBG("sending skbuff on interface %s\n", dev->name);
+
+	stats->tx_packets++;
+	stats->tx_bytes += skb->len;
+
+	/* tx socket reference pointer: Loopback required if not NULL */
+	loop = *(struct sock **)skb->cb != NULL;
+
+	if (!loopback) {
+		/* no loopback handling available inside this driver */
+
+		if (loop) {
+			/*
+			 * only count the packets here, because the
+			 * CAN core already did the loopback for us
+			 */
+			stats->rx_packets++;
+			stats->rx_bytes += skb->len;
+		}
+		kfree_skb(skb);
+		return 0;
+	}
+
+	/* perform standard loopback handling for CAN network interfaces */
+
+	if (loop) {
+		if (atomic_read(&skb->users) != 1) {
+			struct sk_buff *old_skb = skb;
+
+			skb = skb_clone(old_skb, GFP_ATOMIC);
+			DBG(KERN_INFO "%s: %s: freeing old skbuff %p, "
+			    "using new skbuff %p\n",
+			    dev->name, __FUNCTION__, old_skb, skb);
+			kfree_skb(old_skb);
+			if (!skb)
+				return 0;
+		} else
+			skb_orphan(skb);
+
+		/* receive with packet counting */
+		vcan_rx(skb, dev);
+	} else {
+		/* no looped packets => no counting */
+		kfree_skb(skb);
+	}
+	return 0;
+}
+
+static int vcan_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
+{
+	return -EOPNOTSUPP;
+}
+
+static int vcan_rebuild_header(struct sk_buff *skb)
+{
+	DBG("skbuff %p\n", skb);
+	return 0;
+}
+
+static int vcan_header(struct sk_buff *skb, struct net_device *dev,
+		       unsigned short type, void *daddr, void *saddr,
+		       unsigned int len)
+{
+	DBG("skbuff %p, device %p\n", skb, dev);
+	return 0;
+}
+
+
+static struct net_device_stats *vcan_get_stats(struct net_device *dev)
+{
+	struct net_device_stats *stats = netdev_priv(dev);
+
+	return stats;
+}
+
+static void vcan_init(struct net_device *dev)
+{
+	DBG("dev %s\n", dev->name);
+
+	ether_setup(dev);
+
+	memset(dev->priv, 0, STATSIZE);
+
+	dev->type              = ARPHRD_CAN;
+	dev->mtu               = sizeof(struct can_frame);
+	dev->flags             = IFF_NOARP;
+
+	/* set flags according to driver capabilities */
+	if (loopback)
+		dev->flags |= IFF_LOOPBACK;
+
+	dev->open              = vcan_open;
+	dev->stop              = vcan_stop;
+	dev->set_config        = NULL;
+	dev->hard_start_xmit   = vcan_tx;
+	dev->do_ioctl          = vcan_ioctl;
+	dev->get_stats         = vcan_get_stats;
+	dev->hard_header       = vcan_header;
+	dev->rebuild_header    = vcan_rebuild_header;
+	dev->hard_header_cache = NULL;
+
+	SET_MODULE_OWNER(dev);
+}
+
+static __init int vcan_init_module(void)
+{
+	int i, result;
+
+	printk(banner);
+
+	/* register at least one interface */
+	if (numdev < 1)
+		numdev = 1;
+
+	printk(KERN_INFO
+	       "vcan: registering %d virtual CAN interfaces. (loopback %s)\n",
+	       numdev, loopback ? "enabled" : "disabled");
+
+	vcan_devs = kzalloc(numdev * sizeof(struct net_device *), GFP_KERNEL);
+	if (!vcan_devs) {
+		printk(KERN_ERR "vcan: Can't allocate vcan devices array!\n");
+		return -ENOMEM;
+	}
+
+	for (i = 0; i < numdev; i++) {
+		vcan_devs[i] = alloc_netdev(STATSIZE, "vcan%d", vcan_init);
+		if (!vcan_devs[i]) {
+			printk(KERN_ERR "vcan: error allocating net_device\n");
+			result = -ENOMEM;
+			goto out;
+		}
+
+		result = register_netdev(vcan_devs[i]);
+		if (result < 0) {
+			printk(KERN_ERR
+			       "vcan: error %d registering interface %s\n",
+			       result, vcan_devs[i]->name);
+			free_netdev(vcan_devs[i]);
+			vcan_devs[i] = NULL;
+			goto out;
+
+		} else {
+			DBG("successfully registered interface %s\n",
+			    vcan_devs[i]->name);
+		}
+	}
+
+	return 0;
+
+ out:
+	for (i = 0; i < numdev; i++) {
+		if (vcan_devs[i]) {
+			unregister_netdev(vcan_devs[i]);
+			free_netdev(vcan_devs[i]);
+		}
+	}
+
+	kfree(vcan_devs);
+
+	return result;
+}
+
+static __exit void vcan_cleanup_module(void)
+{
+	int i;
+
+	for (i = 0; i < numdev; i++) {
+		if (vcan_devs[i]) {
+			unregister_netdev(vcan_devs[i]);
+			free_netdev(vcan_devs[i]);
+		}
+	}
+
+	kfree(vcan_devs);
+}
+
+module_init(vcan_init_module);
+module_exit(vcan_cleanup_module);
Index: linux-2.6.22-rc1-git4/net/can/Kconfig
===================================================================
--- linux-2.6.22-rc1-git4.orig/net/can/Kconfig	2007-05-16 09:45:00.000000000 +0200
+++ linux-2.6.22-rc1-git4/net/can/Kconfig	2007-05-16 09:45:00.000000000 +0200
@@ -77,3 +77,6 @@
 	  Say Y here if you want the CAN core to produce a bunch of debug
 	  messages to the system log.  Select this if you are having a
 	  problem with CAN support and want to see more of what is going on.
+
+
+source "drivers/net/can/Kconfig"

--