From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wnlzr-0003m3-Vm for qemu-devel@nongnu.org; Fri, 23 May 2014 05:42:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wnlzh-0000wi-2p for qemu-devel@nongnu.org; Fri, 23 May 2014 05:42:39 -0400 Received: from mail-wi0-x22f.google.com ([2a00:1450:400c:c05::22f]:47403) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wnlzg-0000wT-Rs for qemu-devel@nongnu.org; Fri, 23 May 2014 05:42:28 -0400 Received: by mail-wi0-f175.google.com with SMTP id f8so539814wiw.8 for ; Fri, 23 May 2014 02:42:27 -0700 (PDT) Date: Fri, 23 May 2014 11:42:25 +0200 From: Stefan Hajnoczi Message-ID: <20140523094225.GA1260@stefanha-thinkpad.redhat.com> References: <201405092010.19482.pisa@cmp.felk.cvut.cz> <201405151553.07872.pisa@cmp.felk.cvut.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201405151553.07872.pisa@cmp.felk.cvut.cz> Subject: Re: [Qemu-devel] [PATCH 0/2] CAN SJA100 controller emulation and SocketCAN based host CAN bus access List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Pisa Cc: Peter Crosthwaite , Oliver Hartkopp A , jinyang.sia@gmail.com, "qemu-devel@nongnu.org" , rtems-devel@rtems.org, Stefan Weil , linux-can@vger.kernel.org, Andreas =?iso-8859-1?Q?F=E4rber?= On Thu, May 15, 2014 at 03:53:07PM +0200, Pavel Pisa wrote: > The decisions for further development > > Should be minimal working solution included in the QEMU > mainline in short term? > (months .. or rather wait for agreement on final > infrastructure, may be years because of our other load > and complexity of full model task) > > Is preferred approach to open CAN QEMU fork on GitHub? > Etc... It sounds like there is doubt about whether anyone has enough time to implement CAN more fully. I'm not thrilled about reviewing patches if it's a partial implementation with few end users - something like that can be kept out-of-tree until someone with enough resources can polish it and push it upstream. A few more comments about the network subsystem: The QEMU network subsystem doesn't emulate Ethernet. It's just a way to connect an emulated NIC with a host netdev (tap, socket, etc) with a few extra services like link down/up, flow control, etc. In the CAN world it would connect a CAN controller (e.g. Kvaser PCI) with a host device (e.g. using libcan or whatever). I don't think it's necessary to emulate bus arbitration in this model, that should happen via the host device (which is talking to an real CAN bus). The question is whether the network subsystem's send/receive model works or whether you need something CAN-specific like publishing RX/TX objects along with their metadata (IDs, priorities, deadlines, etc). That would be a major difference and it would probably make sense it implement it as a separate subsystem. Stefan