[U-Boot] [PATCH 00/27] virtio: Introduce VirtIO driver support

Bin Meng bmeng.cn at gmail.com
Wed Oct 10 15:35:52 UTC 2018


Hi Simon,

On Wed, Oct 10, 2018 at 12:20 AM Simon Glass <sjg at chromium.org> wrote:
>
> Hi Bin,
>
> On 4 October 2018 at 01:00, Bin Meng <bmeng.cn at gmail.com> wrote:
> > Hi Simon,
> >
> > On Tue, Oct 2, 2018 at 7:22 PM Simon Glass <sjg at chromium.org> wrote:
> >>
> >> Hi,
> >>
> >> On 27 September 2018 at 15:19, Tuomas Tynkkynen <tuomas.tynkkynen at iki.fi> 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.
>

OK, will try to add a simple virtio sandbox driver to validate the API usage.

Regards,
Bin


More information about the U-Boot mailing list