On 29.06.21 21:39, Harald Mommer wrote:
I still don't get it. This service process is the virtio device itself.
All our virtio devices are user land processes. There is no problem,
this works that way.
Works this way ... well, AFAIK virtio devices are usually no user space
implementations.
The problem may be that the virtio device should better not have used
vcan0 to get CAN access and that it should have used something different
instead. CAN GW? Is it that what you want to tell me all the time? "Do
not use vcan0 to exchange CAN messages but use CAN GW"?
You would still still use vcan0 or whatever you name it. But the
"routing between CAN interfaces" can be done more efficiently inside the
kernel.
In this case in
the picture the box "Device Linux / VCAN / vcan0" changes but not the
userland virtio CAN device service process box.
My suggestion is more like: Create a virtual CAN device that exposes the
virtio net driver as a CAN device inside kernel space.
An then you can use can-gw to do filtering/firewalling/forwarding to
different application specific vcan's with can-gw.
If it's this I'll get into CAN GW to understand what all this means now
and how to use it.
Just try this (as root):
modprobe can-gw
cangw -A -s vcan0 -d vcan1 -e
cangw -A -s vcan0 -d vcan2 -e -m OR:ID:400.8.8888888888888888
cangen vcan0
(and candump -c -c any on a second terminal)
This should give an impression. No filtering shown.
But anyway, if so this should not have any impact on the driver or the
spec, this would be an issue of the device implementation itself which
is closed source and should now not be this interesting.
IMO a CAN virtio driver can be from public interest - and it has no USP.
So why putting such a simple thing under closed source?
Regards,
Oliver
ps. Some can-gw / CAN net namespace slideware:
https://wiki.automotivelinux.org/_media/agl-distro/agl2018-socketcan.pdf
