From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52328) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UeSkq-0002W0-6u for qemu-devel@nongnu.org; Mon, 20 May 2013 12:16:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UeSkl-0001CS-8A for qemu-devel@nongnu.org; Mon, 20 May 2013 12:16:08 -0400 Received: from cantor2.suse.de ([195.135.220.15]:51527 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UeSkk-0001CD-VJ for qemu-devel@nongnu.org; Mon, 20 May 2013 12:16:03 -0400 Message-ID: <519A4C3A.2000805@suse.de> Date: Mon, 20 May 2013 18:15:54 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <519918BB.3070608@suse.de> <201305192106.52347.pisa@cmp.felk.cvut.cz> In-Reply-To: <201305192106.52347.pisa@cmp.felk.cvut.cz> 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: Pavel Pisa Cc: Gedare Bloom , Amar Takhar , Petr Benes , Thomas Doerfler , "Sebastian.Huber@embedded-brains.de" , "Rempel, Cynthia" , "qemu-devel@nongnu.org" , Jennifer Averett , Chris Johns , Paolo Bonzini , Cl?udio Silva , Joel Sherrill Hello Pavel, Am 19.05.2013 21:06, schrieb Pavel Pisa: > On Sunday 19 May 2013 20:23:55 Andreas F=E4rber wrote: >> Am 18.05.2013 20:24, schrieb Rempel, Cynthia: >>>>> The RTEMS development community is considering having a Google Summ= er >>>>> 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 devic= e > >>>>> 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 simpl= e > device > -device can-kvasser-pcican-q > or=20 > -device can,model=3Dkvasser-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 --=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