From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Tue, 9 Oct 2018 10:20:23 -0600 Subject: [U-Boot] [PATCH 00/27] virtio: Introduce VirtIO driver support In-Reply-To: References: <1537710145-1888-1-git-send-email-bmeng.cn@gmail.com> <980f13c2-c0df-c4a9-91ec-3bc89ddbd236@iki.fi> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Bin, On 4 October 2018 at 01:00, Bin Meng wrote: > Hi Simon, > > On Tue, Oct 2, 2018 at 7:22 PM Simon Glass wrote: >> >> Hi, >> >> On 27 September 2018 at 15:19, Tuomas Tynkkynen wrote: >> > Hi Simon, >> > >> > On 09/27/2018 04:43 PM, Simon Glass wrote: >> > ... >> >> >> >> >> >> How does this all get tested? Could we have a simple sandbox driver? >> >> >> > >> > We can switch the Travis-CI jobs for the QEMU boards to use virtio-net >> > instead of the current network cards for the TFTP tests. I don't know >> > if there are pytest equivalents for block devices. >> >> We do actually have sandbox block devices and can add anything that is >> needed. While qemu is helpful, I much prefer tests that run with 'make >> tests'. > > I had a look at the testing on sandbox. It looks to me that we need > introduce a non-existent virtio transport sandbox emulator to support > this. I am not sure this is worth to do so. As Tuomas mentioned we can > setup travis-ci to test on qemu targets. I would like to have at least some basic testing of each uclass within U-Boot without relying on qemu, which after all is a much more complicated test. We have created simple sandbox drivers other uclasses and I don't see a good reason why virtio should be different? There are only 11 methods in the uclass so it should not be a huge amount of work to call each one. I certainly understand the burden of this, but I think it will pay off. Regards, Simon