[Qemu-devel] Writing a CAN driver for QEMU

[Qemu-devel] Writing a CAN driver for QEMU

[Rempel, Cynthia]

Hi Qemu-Devel,

I am part of the RTEMS development community.

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?

3. Could we get a co-mentor from qemu-devel to help the student with technical questions, or if not, would this mailing list be willing to help us out?

Thanks,
Cynthia Rempel
RTEMS Development Community

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

[Paolo Bonzini]

Il 17/05/2013 22:29, Rempel, Cynthia ha scritto:> Hi Qemu-Devel,
> I am part of the RTEMS development community.
> 
> 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 this interact with
something in the host (e.g. emulating the sensors)?  Or is it like USB
where QEMU has emulation of both controllers and devices (e.g. tablets
or storage)?

There are lots of different devices in QEMU; a student with good code
reading abilities should be able to find what he needs, but if you are
writing an entire emulation subsystem it's going to be a lot of work.

> 3. Could we get a co-mentor from qemu-devel to help the student with
> technical questions, or if not, would this mailing list be willing to
> help us out?

I don't know if someone is available to mentor the project, but the
mailing list would surely be of help.

Paolo

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

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

>Would this interact with
>something in the host (e.g. emulating the sensors)?  Or is it like USB
>where QEMU has emulation of both controllers and devices (e.g. tablets
>or storage)?

we want to be able to verify a guest OS's CAN driver has been integrated properly and is sending CAN packets... 

Perhaps along the lines of two calls:
qemu-system-arm -hda linux1.img -can student-implemented-device
qemu-system-arm -hda linux2.img -can student-implemented-device

Then using a network protocol analyzer (such as Wireshark) with a custom filter to recognize CAN packets,
OR
qemu-system-arm -hda linux1.img -can student-implemented-device
then attaching a real CAN device to the host computer and verifying that the output is being recognized be real hardware.

Whichever is more feasible to implement...

>There are lots of different devices in QEMU; a student with good code
>reading abilities should be able to find what he needs, but if you are
>writing an entire emulation subsystem it's going to be a lot of work.
Is it feasible to implement an emulation of a CAN device as a Google Summer of Code project? If so, what would be a feasible CAN device to implement? If not, would having the student hook up a real CAN device to an emulated guest OS be feasible to implement as a Google Summer of Code project?

>> 3. Could we get a co-mentor from qemu-devel to help the student with
>> technical questions, or if not, would this mailing list be willing to
>> help us out?
>I don't know if someone is available to mentor the project, but the
>mailing list would surely be of help.
Thanks we really appreciate all the help :)

>Paolo

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

[Stefan Weil]

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?

Yes, I think so.

Here is also some help which shows the fundamental
requirements for new contributions:

http://wiki.qemu.org/Contribute/SubmitAPatch

Are you planning to emulate an existing CAN controller,
or do you want to design a new virtual CAN controller
from scratch?

Regards,
Stefan Weil

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

[Rempel, Cynthia]

>> Would following the guidance in:
>> http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg00842.html
>> increase the probability the [CAN] device simulation would be committed to qemu?
>Yes, I think so.
>
>Here is also some help which shows the fundamental
>requirements for new contributions:
>
>http://wiki.qemu.org/Contribute/SubmitAPatch
Thank you! This is very helpful :)

>
>Are you planning to emulate an existing CAN controller,
>or do you want to design a new virtual CAN controller
>from scratch?
If feasible, we would prefer to emulate a CAN controller that has a LinCan port, so that we have a "known good" software configuration to work with...

http://ortcan.git.sourceforge.net/git/gitweb.cgi?p=ortcan/lincan;a=tree;f=lincan/src

We would want to have the student write an emulation for the CAN portion of one (1) of the CAN controllers... We will want to be able to hook it into qemu-system-arm... which of these controllers would it be more feasible to write an emulation for? 

ADLINK 7841 card
AIM104CAN PC/104 card
BFAD can
C_CAN Bosch
CAN104 PC/104
Kontron EB8245
EMS-WUENSCHE CPC-PCI
CAN/PCI-200
PCI/PMC 266 card
PCAN-PC/104
sja1000 CAN
SH7760 HCAN2
HMS30c7202 C_CAN
i82527 CAN
IXXAT iPC-I 165
KVASER PCIcan
M437 PC/104
MPC5200 MSCAN
PC-I03
PCAN-PCI
PCCCAN board
PCM-3680 PC/104
MX1_DIS1
PIP5,PIP6,PIP7 and PIP8
SJA1000 chip PeliCanCAN
SSV board
TS-7KV multifunction card
Unicontrols PCAN

We really appreciate all the help!
 
>Regards,
>Stefan Weil

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

[Pavel Pisa]

Hello All,

On Saturday 18 May 2013 23:23:28 Rempel, Cynthia wrote:
> >> Would following the guidance in:
> >> http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg00842.html
> >> increase the probability the [CAN] device simulation would be committed
> >> to qemu?
> >
> >Yes, I think so.
> >
> >Here is also some help which shows the fundamental
> >requirements for new contributions:
> >
> >http://wiki.qemu.org/Contribute/SubmitAPatch
>
> Thank you! This is very helpful :)
>
> >Are you planning to emulate an existing CAN controller,
> >or do you want to design a new virtual CAN controller
> >from scratch?
>
> If feasible, we would prefer to emulate a CAN controller that has a LinCan
> port, so that we have a "known good" software configuration to work with...
>
> http://ortcan.git.sourceforge.net/git/gitweb.cgi?p=ortcan/lincan;a=tree;f=l
>incan/src
>
> We would want to have the student write an emulation for the CAN portion of
> one (1) of the CAN controllers... We will want to be able to hook it into
> qemu-system-arm... which of these controllers would it be more feasible to
> write an emulation for?
>
> ADLINK 7841 card
> AIM104CAN PC/104 card
> BFAD can
> C_CAN Bosch
> CAN104 PC/104
> Kontron EB8245
> EMS-WUENSCHE CPC-PCI
> CAN/PCI-200
> PCI/PMC 266 card
> PCAN-PC/104
> sja1000 CAN
> SH7760 HCAN2
> HMS30c7202 C_CAN
> i82527 CAN
> IXXAT iPC-I 165
> KVASER PCIcan
> M437 PC/104
> MPC5200 MSCAN
> PC-I03
> PCAN-PCI
> PCCCAN board
> PCM-3680 PC/104
> MX1_DIS1
> PIP5,PIP6,PIP7 and PIP8
> SJA1000 chip PeliCanCAN
> SSV board
> TS-7KV multifunction card
> Unicontrols PCAN
>
> We really appreciate all the help!

The question is what is the reasonable controller to emulate.
Today, Bosch IP core C_CAN is quite often integrated in devices.
But its windowed message objects access is nightmare.

Some clean simple CAN controller (like FreeScale MSCAN) would
be much simpler to implement, but this is not PCI connected
on any target (mos probably).

So if we speak about chip with broad availability then SJA1000 is
the choice. It complicates things by only 8-bit registers access
and old non-PeliCAN mode for compatibility. But it can be even ignored.
Then it is single Rx object + FIFO based which simplifies implementation.

There exists many PCI boards with SJA1000 behind different PCI/local
buss bridges. Some are quite bizare with strange edge triggered
IRQs routing and combining which requires to be extra carefull
for IRQ processing on driver side.

The board with clean simple design and level interrupts are Kvaser
PCIcan-S, PCIcan-D, PCIcan-Q.
The actual naming is little different but I expect that it is same HW
PCIcan HS, PCIcan HS/HS, PCIcanx 4xHS

  http://www.kvaser.com/en/products/can/pci.html

We have more these cards so we can check even on real HW.

I have found manual there for example

http://simlab.dyndns.org:9000/AllegroHandWiki/images/c/c5/Kvaser_PCIcan_Hardware_Reference_Manual.pdf

So it is good choice for QEMU and Linux (and even for RTEMS if more 
architectures should be supported). The PCIcan-Q has even nice feature
to connect and terminate selected channels directly on board so no external
componets/cables are not required for simple testing.

On the other hand some FPGA design like Gailser GRCAN, MSCAN or FlexCAN
can be simpler when we consider non PCI one system.

By the way, how is it with future possible integration ofMBED 
(http://mbed.org/nxp/lpc1768/) board QEMU support
(https://github.com/gdrane/MBEDSimulator.git).
It LPC17xx is an another candidate.

We should discuss the QEMU CAN controller emulation selection
on linux-can@vger.kernel.org mailing list.

I have information that one big carmaker in cooperation with one
big chip maker has full CAN controller and network model including
bit-timing implemented. But I do not know more and it is possible
that their implementation is to complex for reuse in QEMU (and probly
even not publicable).

But we should discuss on which chip to focuss with SocketCAN
maintainers on linux-can for sure.

Best wishes

                Pavel Pisa
    e-mail:     pisa@cmp.felk.cvut.cz
    www:        http://cmp.felk.cvut.cz/~pisa
    university: http://dce.fel.cvut.cz/
    company:    http://www.pikron.com/

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

[Jean-Christophe PLAGNIOL-VILLARD]

On May 19, 2013, at 8:44 AM, Pavel Pisa <pisa@cmp.felk.cvut.cz> wrote:

> Hello All,
> 
> On Saturday 18 May 2013 23:23:28 Rempel, Cynthia wrote:
>>>> Would following the guidance in:
>>>> http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg00842.html
>>>> increase the probability the [CAN] device simulation would be committed
>>>> to qemu?
>>> 
>>> Yes, I think so.
>>> 
>>> Here is also some help which shows the fundamental
>>> requirements for new contributions:
>>> 
>>> http://wiki.qemu.org/Contribute/SubmitAPatch
>> 
>> Thank you! This is very helpful :)
>> 
>>> Are you planning to emulate an existing CAN controller,
>>> or do you want to design a new virtual CAN controller
>>> from scratch?
>> 
>> If feasible, we would prefer to emulate a CAN controller that has a LinCan
>> port, so that we have a "known good" software configuration to work with...
>> 
>> http://ortcan.git.sourceforge.net/git/gitweb.cgi?p=ortcan/lincan;a=tree;f=l
>> incan/src
>> 
>> We would want to have the student write an emulation for the CAN portion of
>> one (1) of the CAN controllers... We will want to be able to hook it into
>> qemu-system-arm... which of these controllers would it be more feasible to
>> write an emulation for?
>> 
>> ADLINK 7841 card
>> AIM104CAN PC/104 card
>> BFAD can
>> C_CAN Bosch
>> CAN104 PC/104
>> Kontron EB8245
>> EMS-WUENSCHE CPC-PCI
>> CAN/PCI-200
>> PCI/PMC 266 card
>> PCAN-PC/104
>> sja1000 CAN
>> SH7760 HCAN2
>> HMS30c7202 C_CAN
>> i82527 CAN
>> IXXAT iPC-I 165
>> KVASER PCIcan
>> M437 PC/104
>> MPC5200 MSCAN
>> PC-I03
>> PCAN-PCI
>> PCCCAN board
>> PCM-3680 PC/104
>> MX1_DIS1
>> PIP5,PIP6,PIP7 and PIP8
>> SJA1000 chip PeliCanCAN
>> SSV board
>> TS-7KV multifunction card
>> Unicontrols PCAN
>> 
>> We really appreciate all the help!
> 
> The question is what is the reasonable controller to emulate.
> Today, Bosch IP core C_CAN is quite often integrated in devices.
> But its windowed message objects access is nightmare.
> 
> Some clean simple CAN controller (like FreeScale MSCAN) would
> be much simpler to implement, but this is not PCI connected
> on any target (mos probably).

The AT91 is simple too and there is some patch on the ML to add the at91sam9263 SoC

Best Regards,
J.

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

[Peter Maydell]

On 19 May 2013 07:58, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> The AT91 is simple too and there is some patch on the ML to add the
> at91sam9263 SoC

I would recommend against making this project depend on also getting
an entire new SoC and board model into shape to be committed upstream.
You want something which is either part of an existing upstream
QEMU board or which is a pluggable card for a bus QEMU already
supports (like PCI).

thanks
-- PMM

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

[Stefan Weil]

Am 19.05.2013 09:23, schrieb Peter Maydell:
> On 19 May 2013 07:58, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
>> The AT91 is simple too and there is some patch on the ML to add the
>> at91sam9263 SoC
> I would recommend against making this project depend on also getting
> an entire new SoC and board model into shape to be committed upstream.
> You want something which is either part of an existing upstream
> QEMU board or which is a pluggable card for a bus QEMU already
> supports (like PCI).
>
> thanks
> -- PMM

PCI (and USB if they were supported with LinCAN) CAN controller boards
could also be used with x86, so QEMU (with KVM) would be much faster
and use lessresources than an ARM system emulation.

So one of the PCI controllers might be the best choice.

Select one with good documentation, complete implementation (on the
RTEMS / LinCAN side) and small source code (which is typically an
indicator for the complexity - a large complex driver typically
also needs a complex emulation in QEMU).

Regards,
Stefan Weil

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

[Paolo Bonzini]

Il 18/05/2013 20:24, Rempel, Cynthia ha scritto:
> we want to be able to verify a guest OS's CAN driver has been integrated properly and is sending CAN packets... 
> 
> Perhaps along the lines of two calls:
> qemu-system-arm -hda linux1.img -can student-implemented-device
> qemu-system-arm -hda linux2.img -can student-implemented-device

You would probably use either -net, or -netdev and -device (see
docs/qdev-device-use.txt).

> Then using a network protocol analyzer (such as Wireshark) with a custom filter to recognize CAN packets,
> OR
> qemu-system-arm -hda linux1.img -can student-implemented-device
> then attaching a real CAN device to the host computer and verifying that the output is being recognized be real hardware.

Is this CAN device just an Ethernet device?  QEMU does not support other
link-level protocols.  Adding them would be possible and interesting,
however it would add a bit to the complexity.

> Whichever is more feasible to implement...

Both would be the same.  In the first case, you'd probably use "-netdev
socket" to share a virtual network between two virtual machines.  In the
second, you would use something like "-netdev tap" (again assuming it's
just an Ethernet device).

Paolo

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

[Paolo Bonzini]

Il 19/05/2013 14:58, Paolo Bonzini ha scritto:
> Is this CAN device just an Ethernet device?  QEMU does not support other
> link-level protocols.  Adding them would be possible and interesting,
> however it would add a bit to the complexity.
> 
> Both would be the same.  In the first case, you'd probably use "-netdev
> socket" to share a virtual network between two virtual machines.  In the
> second, you would use something like "-netdev tap" (again assuming it's
> just an Ethernet device).

Ok, learnt a bit more...  You could probably implement this in two ways:
1) "-netdev socket" would probably work as a CAN->UDP gateway; 2)
connecting to a virtual CAN interface in the host, created using
SocketCAN (similar to "-netdev tap", e.g. "-netdev cantap").

In the first case, it would probably be useful to write the matching
UDP->CAN gateway program.

In any case, you have to implement both the backend and the actual device.

Paolo

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

[Stefan Weil]

Am 19.05.2013 15:19, schrieb Paolo Bonzini:
> Il 19/05/2013 14:58, Paolo Bonzini ha scritto:
>> Is this CAN device just an Ethernet device?  QEMU does not support other
>> link-level protocols.  Adding them would be possible and interesting,
>> however it would add a bit to the complexity.
>>
>> Both would be the same.  In the first case, you'd probably use "-netdev
>> socket" to share a virtual network between two virtual machines.  In the
>> second, you would use something like "-netdev tap" (again assuming it's
>> just an Ethernet device).
> Ok, learnt a bit more...  You could probably implement this in two ways:
> 1) "-netdev socket" would probably work as a CAN->UDP gateway; 2)
> connecting to a virtual CAN interface in the host, created using
> SocketCAN (similar to "-netdev tap", e.g. "-netdev cantap").
>
> In the first case, it would probably be useful to write the matching
> UDP->CAN gateway program.
>
> In any case, you have to implement both the backend and the actual device.
>
> Paolo

I used TCP instead of UDP in a proprietary solution more than
10 years ago.

CAN devices are connected to CAN buses, so I had a CAN device
emulation (on CAN API level, not on hardware level like with QEMU)
and a CAN bus emulation.

The CAN bus emulation was a TCP server process. It could simulate
several CAN buses.

Each CAN controllerwas a TCP client connected to the CAN bus emulation.

The TCP clients sent CAN data packets (length, packet type and data)
to the TCP server and received such packets from the server.
They also exchanged control packets with the server (topology = which bus,
data rate, CAN filter settings).

The CAN bus emulation routed each received packet to other CAN controllers
on the same bus (CAN is a broadcast protocol) and could also simulate
error packets (for example when there was a mismatch of the data rates
between sender and receiver). In debug mode, the bus emulation could
also display the packets (raw data or CAN Open packets).

Several CAN vendors provide bidirectional CAN-Ethernet gateways,
but I don't know whether there is a standard for CAN-over-Ethernet.

Regards,
Stefan

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

[Andreas Färber]

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.

One point I would like to point out is that QEMU devices don't simulate
their hardware counterpart but instead only emulate them - that is, if
you implement, e.g., a Freescale MPC5604B FlexCAN or Renesas RX62N RCAN
controller you will deal with register accesses coming from the guest
and their abstract concepts like mailboxes and objects rather than
actual line-encodings. So if you want, you might get around some of the
gory details by implementing the device using an abstract CANBus bus
implementation (cf. PCIBus, I2CBus, etc.) and if necessary interfacing
with whatever CAN API on the host directly; if you need to externalize
this through a -chardev command line option for analysis, it probably
requires some more work.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

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

[Andreas Färber]

Hello Pavel,

Am 19.05.2013 21:06, schrieb Pavel Pisa:
> 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?
[...]
>>> 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.
[...]
> 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
[snip]

While using a model property is not wrong per se, "can" seems too
generic as type name, since it needs to inherit from a particular base
class such as PCIDevice. QOM types can be made abstract to share code
between device implementations to the same effect, e.g. PCIHostState.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg