From: Marc Kleine-Budde <mkl@pengutronix.de>
To: John Whitmore <arigead@gmail.com>, linux-can@vger.kernel.org
Subject: Re: vcan multithreaded problem testing
Date: Sun, 16 Feb 2014 12:16:11 +0100 [thread overview]
Message-ID: <53009DFB.5060302@pengutronix.de> (raw)
In-Reply-To: <20140216100428.GC5440@griso.site>
[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]
On 02/16/2014 11:04 AM, John Whitmore wrote:
> Hello all, I'll try keep this short. I'm using vcan to test code I'm porting
> from my embedded hardware. My embedded code has a simple dispatcher which
> process all messages received from the Network. Higher layers of the
> Application register an interest in certain CAN ids or ranges.
>
> I don't need this dispatcher as Socket CAN filters already so in porting my
> application the higher layers now simply create a new linux thread and socket
> to listen for CAN Frames that they have an interest in.
>
> My problem is that in testing with vcan if my core process thead sends a CAN
> id which a child thread is filtering on then the child thread receives the
> message. I've looked at vcan code and it simply consumes the sent frames back
> into the linux networking stack.
>
> At present a single process will not receive a CAN Frame which is sends but
> it's child threads will recive the frame. Is there a way to restrict this? I
> might have to wait until I get back to Hardware and test there but it would be
> very handy to be able to use vcan.
The CAN stack doesn't care about thread or processes, it's all about
sockets.
By default a socket doesn't receive the CAN frame it sends. When a CAN
frame is successfully send, by default all other sockets receive the
locally created CAN frames, too. You can change both defaults. Have a
look at the can.txt documentation in the Linux kernel:
http://lxr.free-electrons.com/source/Documentation/networking/can.txt#L184
http://lxr.free-electrons.com/source/Documentation/networking/can.txt#L502
http://lxr.free-electrons.com/source/Documentation/networking/can.txt#L513
Feel free to ask, if you need more information.
cheers,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]
prev parent reply other threads:[~2014-02-16 11:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-16 10:04 vcan multithreaded problem testing John Whitmore
2014-02-16 11:16 ` Marc Kleine-Budde [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53009DFB.5060302@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=arigead@gmail.com \
--cc=linux-can@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.