From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ue8HD-0003gd-HJ for qemu-devel@nongnu.org; Sun, 19 May 2013 14:24:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ue8H8-0002mA-HR for qemu-devel@nongnu.org; Sun, 19 May 2013 14:24:11 -0400 Received: from cantor2.suse.de ([195.135.220.15]:49444 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ue8H8-0002lh-7e for qemu-devel@nongnu.org; Sun, 19 May 2013 14:24:06 -0400 Message-ID: <519918BB.3070608@suse.de> Date: Sun, 19 May 2013 20:23:55 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: , <51978858.3010205@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Writing a CAN driver for QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Rempel, Cynthia" Cc: Gedare Bloom , Amar Takhar , Petr Benes , Thomas Doerfler , "Sebastian.Huber@embedded-brains.de" , "qemu-devel@nongnu.org" , Jennifer Averett , Chris Johns , Paolo Bonzini , Cl?udio Silva , Joel Sherrill , Pavel Pisa 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? >=20 >> Unfortunately there is not much documentation. >=20 > 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 qe= mu? 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 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg