How to verify linux-next
pintu.ping at gmail.com
Fri Sep 29 23:58:09 EDT 2017
Thanks Mr. Tso for your reply.
Please find my reply inline.
On Sat, Sep 30, 2017 at 3:20 AM, Theodore Ts'o <tytso at mit.edu> wrote:
> 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
I need to submit a patch to mainline which should be verified against
linux-next tree with latest API.
My patch is already working with 4.10 LTS version but I need to upgrade.
> 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?
My patch is related to some test utility based on client/server model.
So, I need 2 terminal, one for server and one for client.
No, I really don't care about distribution, whichever works this way is
good for me. So I a trying both ways: Ububntu(x86) or qemu (arm).
The point is, I should be able to test my patch with linux-next.
> 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, and arm chroots for use in testing Android systems. There
> is also a turn-key images for running tests using the Google Cloud
> Platform, and even a Dockerfile so people can run kernel tests
> using a private Kubernetes cluster.
>  https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-xfstests.md
>  https://thunk.org/android-xfstests
>  https://thunk.org/gce-xfstests
>  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,
> 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
>> 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.
Qemu Busybox -> full feature for me means: I should be able to connect
Qemu with my PUTTY session, and open 2 terminal.
Moreover, I should be able to do scp to my qemu machine from my
> 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. :-)
I am really sorry for the confusion.
Ok, lets talk one by one.
1) How to resolve linux-next build error with ubuntu virtual box 5.1.28
Any quick pointers on this will really help me to quickly verify my
patch and submit.
In file included from ./arch/x86/include/asm/atomic.h:7:0,
arch/x86/kvm/vmx.c: In function ‘__pi_post_block’:
./arch/x86/include/asm/cmpxchg.h:129:2: warning: ‘__ret’ is used
uninitialized in this function [-Wuninitialized]
./arch/x86/include/asm/cmpxchg.h:86:21: note: ‘__ret’ was declared here
__typeof__(*(ptr)) __ret; \
./arch/x86/include/asm/cmpxchg.h:133:2: note: in expansion of macro
__raw_cmpxchg((ptr), (old), (new), (size), LOCK_PREFIX)
./arch/x86/include/asm/cmpxchg.h:148:2: note: in expansion of macro ‘__cmpxchg’
__cmpxchg(ptr, old, new, sizeof(*(ptr)))
arch/x86/kvm/vmx.c:11732:11: note: in expansion of macro ‘cmpxchg’
} while (cmpxchg(&pi_desc->control, old.control,
In function ‘__pi_post_block’,
inlined from ‘pi_post_block’ at arch/x86/kvm/vmx.c:11831:2,
inlined from ‘vmx_post_block’ at arch/x86/kvm/vmx.c:11840:2:
./arch/x86/include/asm/cmpxchg.h:127:3: error: call to
‘__cmpxchg_wrong_size’ declared with attribute error: Bad argument
size for cmpxchg
> - Ted
More information about the Kernelnewbies