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
