Hi
I am able to boot my custom kernel off of bare hardware, but when I try to boot
this with qemu it hangs after first two lines of print about BIOS. i tried
booting through qemu image and also via '-kernel' arg. same result in both
cases. i verified that with same qeumu-system-x86_64 i could boot ubuntu
kernel/initrd in qemu image and also with -kernel arg but not my kernel.
i'm using pc-bios dir as is with all its subdirs and using it as "-L
path_to_pc-bios". can someone help me understand what could be going on.
appreciate your help.
kd
________________________________
From: Anthony Liguori <anth...@codemonkey.ws>
To: Alexander Graf <ag...@suse.de>
Cc: qemu-devel@nongnu.org; Paul Brook <p...@codesourcery.com>; Julian Pidancet
<julian.pidan...@citrix.com>; Gerd Hoffmann <kra...@redhat.com>
Sent: Mon, May 17, 2010 3:46:14 PM
Subject: Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver
On 05/17/2010 05:26 PM, Alexander Graf wrote:
> I'm trying to think of a project where the clean separation between multiple
> video outputs implemented in the backend and a separate frontend worked out.
> So far the only case that has a strikingly similar architecture coming to my
> mind is mplayer. And I wouldn't call mplayer's GUI story a huge success.
>
> In fact, couldn't we rather keep all graphic output out of qemu and just
> expose VNC, possibly with self-made additions to the protocol to speed up
> local rendering (thinking an SHM extension here)?
I think the whole reason this has failed is that if the GUI is a separate
project, the path of least resistance is to use existing interfaces instead of
inventing new ones. That means these GUIs tend to be restricted by whatever
management interface exists which isn't actually good enough.
You really need to have the GUI as part of the main project such that when it
needs a new interface, it can be added very easily.
> Then we could still offer a separate SDL based viewer that could do the
> same things it does now. But we'd also open up the gate for a whole new
> integration level with possible GUIs.
>
You could, but I think it introduces more complexity which just is going to get
in the way of building a good GUI.
Regards,
Anthony Liguori
> Alex
>
>
