|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH 4 of 5] [UPDATE] DisplayState interface change |
Date: | Mon, 24 Nov 2008 13:58:57 -0600 |
User-agent: | Thunderbird 2.0.0.17 (X11/20080925) |
Stefano Stabellini wrote:
Anthony Liguori wrote:If am not mistaken this is exactly what Paul proposed. As I said before, this model is certainly more elegant, but presents some hidden issues: what do we do with the text consoles? Right now a single DisplayState is shared between a graphic console and multiple text console. Do we really want to allocate a buffer each? Who is going to do the console multiplexing?
We really should have a DisplayState that multiplexes multiple DisplayStates. TextConsole should just provide a DisplayState that can be multiplexed.
Even though the QEMUConsole abstraction is not very elegant and should probably be improved I believe it is a different and independent issue from the one addressed in this series.
I'm not asking you to do that refactoring. But since we all pretty much agree that this is how things should look, I want to make sure that the DisplayState API takes all of this into account.
So in that vein, I'd like to see all the things that call graphic_console_init changed to not take a DisplayState, but rather to have graphic_console_init() return an allocated DisplayState. These functions should then return a DisplayState which can be passed to VNC/SDL.
From what I can tell, this is not a huge change. You shouldn't have to really touch any of the console code. I think this is important to sure up what the DisplayState API looks like and how the rest of QEMU interacts with it.
If this seems like a major refactoring, let me know and either you're misunderstanding what I'm suggesting or I've miscalculated how much change is required here :-)
Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |