> On Mar 17, 2017, at 7:41 AM, Vincent JARDIN <vincent.jar...@6wind.com> wrote: > > Let's be back to 2014 with Qemu's thoughts on it, > +Stefan > https://lists.linuxfoundation.org/pipermail/virtualization/2014-June/026767.html > > and > +Markus > https://lists.linuxfoundation.org/pipermail/virtualization/2014-June/026713.html > >> 6. Device models belong into QEMU >> >> Say you build an actual interface on top of ivshmem. Then ivshmem in >> QEMU together with the supporting host code outside QEMU (see 3.) and >> the lower layer of the code using it in guests (kernel + user space) >> provide something that to me very much looks like a device model. >> >> Device models belong into QEMU. It's what QEMU does. > > > Le 17/03/2017 à 00:17, Stephen Hemminger a écrit : >> On Wed, 15 Mar 2017 04:10:56 +0000 >> "O'Driscoll, Tim" <tim.odrisc...@intel.com> wrote: >> >>> I've included a couple of specific comments inline below, and a general >>> comment here. >>> >>> We have somebody proposing to add a new driver to DPDK. It's standalone and >>> doesn't affect any of the core libraries. They're willing to maintain the >>> driver and have included a patch to update the maintainers file. They've >>> also included the relevant documentation changes. I haven't seen any >>> negative comment on the patches themselves except for a request from John >>> McNamara for an update to the Release Notes that was addressed in a later >>> version. I think we should be welcoming this into DPDK rather than >>> questioning/rejecting it. >>> >>> I'd suggest that this is a good topic for the next Tech Board meeting. >> >> This is a virtualization driver for supporting DPDK on platform that >> provides an alternative >> virtual network driver. I see no reason it shouldn't be part of DPDK. Given >> the unstable >> ABI for drivers, supporting out of tree DPDK drivers is difficult. The DPDK >> should try >> to be inclusive and support as many environments as possible.
+2!! for Stephen’s comment. >> > > On Qemu mailing list, back to 2014, I did push to build models of devices > over ivshmem, like AVP, but folks did not want that we abuse of it. The Qemu > community wants that we avoid unfocusing. So, by being too much inclusive, we > abuse of the Qemu's capabilities. > > So, because of being "inclusive", we should allow any cases, it is not a > proper way to make sure that virtio gets all the focuses it deserves. > > Regards, Keith
