From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 521C98A2 for ; Wed, 13 Aug 2014 17:11:02 +0000 (UTC) Received: from mail.active-venture.com (mail.active-venture.com [67.228.131.205]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 9D62B20274 for ; Wed, 13 Aug 2014 17:11:01 +0000 (UTC) Message-ID: <53EB9C23.1060706@roeck-us.net> Date: Wed, 13 Aug 2014 10:10:59 -0700 From: Guenter Roeck MIME-Version: 1.0 To: "Bird, Tim" , Andy Lutomirski References: <53E38ED5.9000300@samsung.com> <53E43365.50809@hitachi.com> <53E8CF03.6020308@samsung.com> <53E8EB93.8030301@hitachi.com> <20140812130043.4894DC40C5C@trevor.secretlab.ca> <53EB8E4F.9090008@roeck-us.net>, In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "shuah.kh@samsung.com" , Rob Landley , "ksummit-discuss@lists.linuxfoundation.org" , Greg Kroah-Hartman Subject: Re: [Ksummit-discuss] kselftest - What's in 3.17 and plans for 3.18 and beyond List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 08/13/2014 09:44 AM, Bird, Tim wrote: > On Wednesday, August 13, 2014 9:16 AM,Andy Lutomirski wrote: >> >> On Wed, Aug 13, 2014 at 9:11 AM, Guenter Roeck wrote: >>> On 08/13/2014 01:35 AM, Linus Walleij wrote: >>>> >>>> On Tue, Aug 12, 2014 at 3:00 PM, Grant Likely wrote: >>>>> I'm interested in this as well. I'm working on a tool that crossbuilds a >>>>> very simple busybox rootfs and boots in QEMU for as many architectures >>>>> as possible. I want to make it easy to sanity test all the major >>>>> architectures. Right now it does little more than boot to a login >>>>> prompt, but I'd like to get the kselftests into it also. >>>> >>>> >>>> Hm that sounds like a goal similar to what Rob Landley has >>>> described as one goal for Aboriginal Linux as well. >>>> http://landley.net/aboriginal/about.html >>>> >>> >>> Yes, and to some degree buildroot. >>> >>> Rob's attempts to support multiple architectures also shows its limitations. >>> For example, his m68k images don't work, at least not for me, because the >>> machine he uses (q800) is not supported in qemu 1.6 or 2.0 or 2.1. >>> I have been unable to find a working combination of kernel configuration, >>> qemu version, qemu command line, and root file system for m68k. Presumably >>> that must exist, because qemu supports m68k, I just have not been able >>> to figure out how to make it work. >>> >>> For my own qemu runtime tests, I ended up collecting root file systems and >>> kernel configurations from all over the place. And then there is the problem >>> of qemu command line parameters, where each target and architecture requires >>> its own set of options, and it is sometimes all but impossible to find a >>> working set of parameters for a given target/architecture combination. >>> >> >> virtme has exactly this problem (except for the root image part -- >> virtme can use debootstrap output directly). In virtme, I'm trying to >> solve it by just collecting known-working QEMU arguments and >> documenting the corresponding kernel config requirements. > > I'm wondering if the kernel test tree might be a good place to keep such > virtual machine/QEMU configurations. They should be only about 1 line > (or a few lines) per machine, and they would be useful for automated testing. > I also think they won't change every kernel release, so it shouldn't lead to the churn > problem we had with defconfigs. > You would also need working configurations. There may be a few exceptions, where one of the defconfigs can be used as is, but in most cases at least some minor tweaks are needed to create a kernel that is working with qemu. Or at least that is my experience. Guenter