Re: [Qemu-devel] Writing a CAN driver for QEMU

[Pavel Pisa]

Hello Andreas and others,

On Sunday 19 May 2013 20:23:55 Andreas Färber wrote:
> Am 18.05.2013 20:24, schrieb Rempel, Cynthia:
> >>> The RTEMS development community is considering having a Google Summer
> >>> of Code student test LinCAN on a simulated RTEMS target board using
> >>> QEMU, and have some questions:
> >>>
> >>> 1. What guidelines should the student follow when writing the device >
> >>> simulation, so the device simulation will be "upstreamed"/accepted by
> >>> the QEMU project?
> >>> 2. Is there additional documentation on how to write a device
> >>> simulation?
> >>
> >> Unfortunately there is not much documentation.
> >
> > Would following the guidance in:
> > http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg00842.html
> > increase the probability the device simulation would be committed to
> > qemu?
>
> Unfortunately that is out of date as far as the code goes (QOM is our
> successor to qdev), but it might serve as a good starting point.
> I emailed you my KVM Forum slides on QOM with a device skeleton to use
> as a starting point.

1) I think that for Linux the best option is to implement that as simple
device
  -device can-kvasser-pcican-q
or 
  -device can,model=kvasser-pcican-q
and use Linux mainlined SocketCAN API to connect virtual device
to real CAN hardware (SocketCAN allows multiple applications access)
or to SocketCAN Virtual CAN (vcan - TCP/IP lo equivalent).
This is straightforward and would result in minimal overhead and latency.

2) If the portability is a problem, then we can create UDP socket
and use it send CAN messages as packets (but it is newer able to
model and pas over real CAN bus behavior, i.e. there are no silently
lost messages on CAN side due to ACK). We have done prototype
of SocketCAN to Ethernet gateway (in user-space and in Linux kernel)
on contract with SocketCAN project. So we can offer some part of
the code for reuse. Code is open/GPLed.

3) The option is to provide both above method or even pull in OrtCAN
VCA (virtual can API) library which can route CAN messages to SocketCAN,
LinCAN and possibly other targets.

Problem is that there is knowledge but amount of work could easily
exceed RTEMS GSoC resources. So I would incline personally to 1).
But opinions, help, documentation etc are welcomed.

Best wishes,

               Pavel