From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvAUP-0004S1-OG for qemu-devel@nongnu.org; Wed, 08 Feb 2012 11:35:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvAUJ-00068F-Ij for qemu-devel@nongnu.org; Wed, 08 Feb 2012 11:35:25 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:56986) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvAUJ-000683-BF for qemu-devel@nongnu.org; Wed, 08 Feb 2012 11:35:19 -0500 Received: by pbbro12 with SMTP id ro12so829132pbb.4 for ; Wed, 08 Feb 2012 08:35:18 -0800 (PST) Message-ID: <4F32A442.1090206@codemonkey.ws> Date: Wed, 08 Feb 2012 10:35:14 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1328687721-16030-1-git-send-email-peter.crosthwaite@petalogix.com> <201202081557.48450.paul@codesourcery.com> <201202081615.30937.paul@codesourcery.com> In-Reply-To: <201202081615.30937.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-6; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Peter Crosthwaite , peter.maydell@linaro.org, aliguori@us.ibm.com, Alexander Graf , qemu-devel@nongnu.org On 02/08/2012 10:15 AM, Paul Brook wrote: >> Ok, that sounds more workable :). So i would add my initrd_addr property to >> the bootloader as a qdev prop as I suggested before, then something like: >> >> qemu-system-arm -M verstailepb -property >> /foo/bar/arm_linux_loader.0,initrd_addr=0x10000000 > > Yes. > > There are various implementation/syntax details to resolve, but in principle I > think it should work a lot like that. There's already a qom-set that takes a path, property, and value. It works with Visitors. To bridge this to the command line, you would need to make a Visitor that defined some syntax for mapping strings to types (pretty trivial really). But before we can even think about this, we need to refactor the device model such that we have a clean separation between initial creation (including creation of children devices) and initialization that requires properties to be set (realization). I posted a series for the i440fx that started doing this refactoring for the PC. Regards, Anthony Liguori > > Paul >