Sebastian Haas | 2 Jan 13:59 2012

[ANNOUNCEMENT] CAN restbus-simulation the Node-way

Hello everybody,

I've recently started to work on restbus-simulation based on SocketCAN. 
Since it is now somewhat useable I decided to announce it here to find 
some advise and helpers to proceed even faster.

The preliminary name is RestCAN. It basically consists of a set of Node 
modules (nodejs.org), which enable the user to develop the behaviour of 
CAN node within a "simple to write" Javascript.

Background
==========
The idea was born because of my personal need to test CAN nodes by 
simulating certain parts of a network. And I also wanted to have a 
simple to use sandbox to implement and test new protocols or control 
algorithms.

I decided to use Javascript because this language is subject of current 
optimization efforts (Webkit, V8, SpiderMonkey). To provide and powerful 
development environment I switched to use NodeJS instead of using V8 
from scratch. NodeJS is a asynchronous event oriented Javascript 
environment with tons of third party modules (NPM) and a good subset of 
builtin utilities (File I/O, TCP/UDP, HTTP, IPC, ...).

Current status
==============
The current status is a Node module to work with raw channels, so a user 
can write a script to send and receive raw CAN messages.

Example
(Continue reading)

Oliver Hartkopp | 3 Jan 19:40 2012
Picon

[PATCH] CAN MAINTAINERS update

Update the CAN MAINTAINERS section:

- point out active maintainers
- pull the CAN driver discussion away from netdev ML
- point to the new CAN web site on gitorious.org
- add CAN development git repository URL to submit patches

Signed-off-by: Oliver Hartkopp <socketcan <at> hartkopp.net>

CC: Oliver Hartkopp <oliver.hartkopp <at> volkswagen.de>
CC: Urs Thuermann <urs.thuermann <at> volkswagen.de>
CC: Wolfgang Grandegger <wg <at> grandegger.com>
CC: Marc Kleine-Budde <mkl <at> pengutronix.de>
CC: linux-can <at> vger.kernel.org

---

Hello Dave,

this is the updated MAINTAINERS section for the CAN subsystem.

As Marc Kleine-Budde will send upcoming git pull requests we discussed, if we
would need an additional section like this ...

NETWORKING [CAN]
M:	Marc Kleine-Budde <mkl <at> pengutronix.de>
L:	linux-can <at> vger.kernel.org
W:	http://gitorious.org/linux-can
T:	git://gitorious.org/linux-can/linux-can-next.git
S:	Maintained
(Continue reading)

David Miller | 3 Jan 19:55 2012
Picon

Re: [PATCH] CAN MAINTAINERS update

From: Oliver Hartkopp <socketcan <at> hartkopp.net>
Date: Tue, 03 Jan 2012 19:40:28 +0100

> Update the CAN MAINTAINERS section:
> 
> - point out active maintainers
> - pull the CAN driver discussion away from netdev ML
> - point to the new CAN web site on gitorious.org
> - add CAN development git repository URL to submit patches
> 
> Signed-off-by: Oliver Hartkopp <socketcan <at> hartkopp.net>

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Joe Perches | 3 Jan 20:26 2012

Re: [PATCH] CAN MAINTAINERS update

On Tue, 2012-01-03 at 19:40 +0100, Oliver Hartkopp wrote:
> Update the CAN MAINTAINERS section:
> - add CAN development git repository URL to submit patches
[]
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
>  <at>  <at>  -1698,11 +1698,9  <at>  <at>  F:	arch/x86/include/asm/tce.h
>  CAN NETWORK LAYER
[]
> +T:	git://gitorious.org/linux-can/linux-can-next.git
[]
>  <at>  <at>  -1713,9 +1711,10  <at>  <at>  F:	include/linux/can/gw.h
>  CAN NETWORK DRIVERS
[]
> +T:	git://gitorious.org/linux-can/linux-can-next.git

Both of the "T:" lines should be:

T:	git git://gitorious.org/linux-can/linux-can-next.git

Oliver Hartkopp | 3 Jan 20:55 2012
Picon

[PATCH] fix CAN MAINTAINERS SCM tree type

As pointed out by Joe Perches the SCM tree type was missing in my patch.

Signed-off-by: Oliver Hartkopp <socketcan <at> hartkopp.net>

CC: Oliver Hartkopp <oliver.hartkopp <at> volkswagen.de>
CC: Urs Thuermann <urs.thuermann <at> volkswagen.de>
CC: Wolfgang Grandegger <wg <at> grandegger.com>
CC: Marc Kleine-Budde <mkl <at> pengutronix.de>
CC: linux-can <at> vger.kernel.org

---

diff -u -r a/MAINTAINERS b/MAINTAINERS
--- a/MAINTAINERS	2012-01-03 20:48:07.160746574 +0100
+++ b/MAINTAINERS	2012-01-03 20:48:51.208745047 +0100
 <at>  <at>  -1700,7 +1700,7  <at>  <at> 
 M:	Oliver Hartkopp <socketcan <at> hartkopp.net>
 L:	linux-can <at> vger.kernel.org
 W:	http://gitorious.org/linux-can
-T:	git://gitorious.org/linux-can/linux-can-next.git
+T:	git git://gitorious.org/linux-can/linux-can-next.git
 S:	Maintained
 F:	net/can/
 F:	include/linux/can.h
 <at>  <at>  -1714,7 +1714,7  <at>  <at> 
 M:	Marc Kleine-Budde <mkl <at> pengutronix.de>
 L:	linux-can <at> vger.kernel.org
 W:	http://gitorious.org/linux-can
-T:	git://gitorious.org/linux-can/linux-can-next.git
+T:	git git://gitorious.org/linux-can/linux-can-next.git
(Continue reading)

David Miller | 3 Jan 20:57 2012
Picon

Re: [PATCH] fix CAN MAINTAINERS SCM tree type

From: Oliver Hartkopp <socketcan <at> hartkopp.net>
Date: Tue, 03 Jan 2012 20:55:58 +0100

> As pointed out by Joe Perches the SCM tree type was missing in my patch.
> 
> Signed-off-by: Oliver Hartkopp <socketcan <at> hartkopp.net>
> 
> CC: Oliver Hartkopp <oliver.hartkopp <at> volkswagen.de>
> CC: Urs Thuermann <urs.thuermann <at> volkswagen.de>
> CC: Wolfgang Grandegger <wg <at> grandegger.com>
> CC: Marc Kleine-Budde <mkl <at> pengutronix.de>
> CC: linux-can <at> vger.kernel.org

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Kurt Van Dijck | 4 Jan 10:47 2012
Picon

Re: using can-j1939

On Wed, Dec 28, 2011 at 10:49:39AM +0000, Wolfgang wrote:
> Hi,
> 
> am I right, if I start for every pgn I want to bridge a new process? Or will it
> work if all pgns to be bridged are in one process? I'm just wondering what will
> bring a better performance? 
A third option is to start 1 process, with different sockets, each socket bridging 1 pgn.

They all work.
I have no idea what will bring the best performance.
I think your second option will bring:
* the most understandable source code...
* less memory consumption
* less scheduler load
* more transparency (FIFO operation is lost when using different processes)

Kurt
> 
> --Wolfgang
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Wolfgang Grandegger | 4 Jan 14:10 2012

Re: [PATCH net-next v2 2/4] can: cc770: add legacy ISA bus driver for the CC770 and AN82527

Hi Wolfgang,

On 12/31/2011 10:39 AM, Wolfgang Zarre wrote:
> Hello Wolfgang,
> 
>> Hello Wolfgang,
>>> Hi Wolfgang,
>>>
>>> On 12/21/2011 07:32 PM, Wolfgang Zarre wrote:
>>>> Hello Wolfgang,
>>> ...
>>>
>>>
>>> Again, please check if you have netif_start_queue() at the end of the
>>> open function.
>>>
>>
>> As said I'm using eec921ac28fde243456078a557768808d93d94a3
>>
>> However, I'll try further to investigate that issue due the fact
>> having it
>> running with my lincan without problems and therefore it should be
>> possible
>> to find the problem.
>>
> 
> I found the problem which was then at the end quite simple to understand
> why it
> get stuck due the fact not receiving an interrupt for TX and due that no
> reactivation of the queue.
(Continue reading)

Wolfgang | 4 Jan 17:28 2012
Picon

recv list

Hi,

OK, I create 1 socket for one source address (what is the maximum of pgns per 
socket?). 
So if I use recvfrom for one specific pgn - while waiting for that specific pgn
the other pgns from that src address are stored in the buffer of the socket and
will be later "recvfrom"? So no can frame will be lost?

Am I right, with this, only the j1939 frame with id<0x19233000> should be
received, but nothing is done, (just waiting for anything), what have I done 
wrong?

#include <sys/ioctl.h>
#include <net/if.h>
#include <string.h>
#include <linux/can/j1939.h>
#include <linux/can.h>
#include <unistd.h>
#include <sys/socket.h>
#include <stdio.h>
#include <sys/types.h>

int main (void)
{
	int s;
	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	    
	struct sockaddr_can addr;

    memset(&addr, 0, sizeof(addr));
(Continue reading)

Kurt Van Dijck | 4 Jan 21:41 2012
Picon

Re: recv list

On Wed, Jan 04, 2012 at 04:28:46PM +0000, Wolfgang wrote:
> Hi,
> 
> OK, I create 1 socket for one source address (what is the maximum of pgns per 
> socket?). 
a bit unlimited, use filters there.
> So if I use recvfrom for one specific pgn - while waiting for that specific pgn
Nope,
man recvfrom ....

can-j1939 will store the source address & PGN into the 'src_addr' (called dest_addr
in your example).
You cannot pick a specific PGN from the incoming queue.

> the other pgns from that src address are stored in the buffer of the socket and
> will be later "recvfrom"? So no can frame will be lost?
> 
> Am I right, with this, only the j1939 frame with id<0x19233000> should be
> received, but nothing is done, (just waiting for anything), what have I done 
> wrong?
> 
> #include <sys/ioctl.h>
> #include <net/if.h>
> #include <string.h>
> #include <linux/can/j1939.h>
> #include <linux/can.h>
> #include <unistd.h>
> #include <sys/socket.h>
> #include <stdio.h>
> #include <sys/types.h>
(Continue reading)


Gmane