[Automated-testing] board/vm management layer verbs for syzbot

[Tim.Bird at sony.com]

> -----Original Message-----
> From: Dmitry Vyukov on  Monday, October 07, 2019 3:40 PM
> 
> On Tue, Oct 8, 2019 at 1:11 AM <Tim.Bird at sony.com> wrote:
> >
> > Dmitry,
> >
> > In our hallway conversation at Plumbers we talked about the
> > functions used for syzbot to control and/or communicate
> > with the system under test.  I wrote them down somewhere, but I
> > can't find them now.
> >
> > I believe you said something like "we only use a small number of functions"
> > (like 4 or so).
> >
> > Can you tell me what these are, or point to where I can find them in
> > the syzbot source code?
> >
> > Just for comparison, Fuego uses the following, which we call our
> > "transport" APIs:
> >  * cmd - execute a command on the device under test
> >  * put - copy files and/or directories to the device under test
> >  * get - copy files and/or directories from the device under test
> >
> > And ones that we consider our board management API:
> >  * setup - can be used for provisioning a board or instantiating a vm
> >  * teardown - used for instance destruction (for vms)
> >  * reboot - reboot the device under test
> 
> Hi Tim,
> 
> Here is the interface:
> https://github.com/google/syzkaller/blob/28ac6e6496673327d3319bab81c57
> a0f7366fb45/vm/vmimpl/vmimpl.go#L32-L57
> 
> Some comments:
>  - when Instance is created, it's supposed to be a "good" state (e.g.
> rebooted)
>  - Close ("destructor") should take care of doing tear down, returning
> back to pool, etc
>  - for Copy operation we don't specify destination path, it's supposed
> to be chosen by the impl (different machines can have writable storage
> at different paths); this is fine for our use case of copying a few
> files into a single dir; a more flexible interface would allow
> choosing a suffix of the path on the target machine (impl will choose
> a path prefix, but you can still re-create a particular dir layout on
> the target)
>  - port forwarding may look a bit specialized for our use case, but we
> want to connect back to the host over tcp (for a richer rpc protocol);
> maybe we could limit this to just 1 port which is specified during
> construction (not dynamically, e.g. qemu port forwarding can be setup
> only when you start the instance, not later)
>  - Run method is designed for long-running processes, so it streams
> output and can be aborted; also the console output is included in the
> command output, which may not be the best decision (it's always
> possible to merge it later, but not possible to unmerge)
>  - Diagnose is newer addition and can be used to provoke
> machine/OS-dependent diagnostics output on the console (because we do
> care a lot about kernel crashes/hangs and ability to understand what
> happened later based on console output)

Very interesting.  Thanks for the quick response.

I'm gathering information on different board management APIs
at https://elinux.org/Board_Management_Layer_Notes

 -- Tim