From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:58811)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Paul_Brook@mentor.com>) id 1RvSjI-0003FS-7x
	for qemu-devel@nongnu.org; Thu, 09 Feb 2012 07:04:06 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Paul_Brook@mentor.com>) id 1RvSjG-0001k4-7l
	for qemu-devel@nongnu.org; Thu, 09 Feb 2012 07:03:59 -0500
Received: from relay1.mentorg.com ([192.94.38.131]:62532)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Paul_Brook@mentor.com>) id 1RvSjG-0001gm-0W
	for qemu-devel@nongnu.org; Thu, 09 Feb 2012 07:03:58 -0500
From: Paul Brook <paul@codesourcery.com>
Date: Thu, 9 Feb 2012 12:03:45 +0000
References: <1328687721-16030-1-git-send-email-peter.crosthwaite@petalogix.com>
	<4F32A442.1090206@codemonkey.ws>
	<CAEgOgz76hOoTiA3xz5J9UJjUBbf5g-cM=o7pnXvUcCXuKY60Mw@mail.gmail.com>
In-Reply-To: <CAEgOgz76hOoTiA3xz5J9UJjUBbf5g-cM=o7pnXvUcCXuKY60Mw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-6"
Content-Transfer-Encoding: 7bit
Message-Id: <201202091203.46171.paul@codesourcery.com>
Subject: Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Peter Crosthwaite <peter.crosthwaite@petalogix.com>, peter.maydell@linaro.org, aliguori@us.ibm.com, Alexander Graf <agraf@suse.de>

>     /* multicore boards that use the default secondary core boot functions
>      * can ignore these two function calls. If the default functions won't
>      * work, then write_secondary_boot() should write a suitable blob of
>      * code mimicing the secondary CPU startup process used by the board's
>      * boot loader/boot ROM code, and secondary_cpu_reset_hook() should
>      * perform any necessary CPU reset handling and set the PC for thei
>      * secondary CPUs to point at this boot blob.
>      */
>     void (*write_secondary_boot)(CPUState *env,
>                                  const struct arm_boot_info *info);
>     void (*secondary_cpu_reset_hook)(CPUState *env,
>                                      const struct arm_boot_info *info);
> };
> 
> The addresses, ints and string are easy, but the hard ones are the
> callbacks. The qdev ptr is a possible implementation but I see a movement
> away from that. I guess the solution is to provide an abstraction through
> QOM no? The boards that need to implement their own secondary
> boot-loop/reset (theres only 1) or atag boot sequence (again only 1) create
> an object that inherits for the arm boot device and instantiate that?

This sounds like an ideal use-case for derived classes and virtual functions.

Paul