On Fri, Sep 29, 2017 at 07:56:41PM +0530, Pintu Kumar wrote: > BTW, I am more interested in my another query about QEMU arm. > This will be much quicker and easy for me. > But the problem is I wanted to use multiple ssh shell on qemu. > Also I needed a pre-built rootfs image for qemu-arm, cortex-a9 > versatilepb machine. If you want to get more useful help, it might be interesting if you were to specify exactly what kind of "verification" you are interested in doing. What sort of kernel testing are you interested in doing? What part of the kernel are you interested in testing? The fact that you are trying to test both a Ubuntu x86 box as will as a virtual ARM box makes it unclear what part of the kernel you are most intested in testing. In particular, why do you care about accessing the VM via ssh / networking? What sort of testing do you plan to do after manage to get the kernel running? And do you care what distribution you use? I have a huge amount of test automation built for testing kernel file systems. This includes building root_fs images for x86 for use with kvm[1], and arm chroots for use in testing Android systems[2]. There is also a turn-key images for running tests using the Google Cloud Platform[3], and even a Dockerfile[4] so people can run kernel tests using a private Kubernetes cluster. [1] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-xfstests.md [2] https://thunk.org/android-xfstests [3] https://thunk.org/gce-xfstests [4] https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/Dockerfile If you don't have a file-system centric view of the world, and want to do more generalized kernel testing, the above might not be as interesting to you, although some of the utilities in the xfstests-bld git tree for setting up and building in build chroots, using debootstrap to create root_fs.img files, scripts for manipulating xUnit test result files (the XML format used by Jenkins), using 9p to communicate between the host system running qemu/kvm and the test VM, etc. The point is that if you really want to get serious about kernel testing, you should really think hard about test automation. And in that world, using networking often makes things harder, not easier. For kvm-xfstests we just do our communications using the serial port, which made it easy for us to adapt things for android-xfstests, where we comunicate test runner script via "adb shell". For gce-xfstests things _do_ get a bit more complicated, where the test summary gets e-mail'ed back to the developer, while the full set of test artifacts are archived on Google Cloud Storage. But one of the most powerful things about my setup is vast majority of the test automation code stays the same regardless of whether the kernel being tested is being run in KVM, on a physical Android hardware, or in the Cloud using GCE. > 2) Let, please point me to a pre-built qemu-arm busy box image with > full features. Define "full features". Busy box images are generally _not_ full featured. There is a reason why I use a minimal Debian system; a lot of the tests I run require bash, and modern shell utilities, and Python so I can have scripts which manipulate xUnit XML files. Nevertheless, the complete x86 test VM is still only 87 megs, which is still small enough that it doesn't cause me any problems. On the other hand, since I find networking in the test VM to be completely superfluous (and in fact, gets in the way, since a VM which is on the corporate network can be a security problem, and may run afoul of corporate I/T security policies --- and if you don't have those kinds of security policies, you really should....). So my root_fs's general have no networking support whatsoever. It keeps $WORK's secops team *much* happier. :-) - Ted _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
