All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Baboval <baboval@spineless.org>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Multi-head support RFC
Date: Tue, 19 Nov 2013 09:17:12 -0500	[thread overview]
Message-ID: <528B72E8.6070307@spineless.org> (raw)
In-Reply-To: <1384844223.16718.93.camel@nilsson.home.kraxel.org>

On 11/19/2013 1:57 AM, Gerd Hoffmann wrote:
>    Hi,
>
>> I think it would be better if the HwOps calls all took a QemuConsole
>> instead of the opaque structure. The hw implementations can dig their
>> opaque structure out from there.
> QemuConsole is private to ui/console.c though (and I prefer to keep it
> this way).  So we need either a helper function to query con->hw or we
> keep the opaque and pass QemuConsole as additional parameter.
>
> When going this route.
>
> Alternative approach:
>
> struct my_gfx_card_state {
>      PCIDevice pci;
>      [ ... ]
>      struct my_head_state {
>          QemuConsole *con;
>          [ ... ]
>      } heads[MAX_HEADS];
> }
>
> Then instead of
>
>     graphic_console_init(..., &state);
>
> call
>
>     graphic_console_init(..., &state->heads[i]);
>
> so you can figure the head in the callbacks.

What I had prototyped (I got impatient) was to add a helper: 
qemu_console_hw_opaque() to console.c so the HwOps could query the 
opaque pointer. I don't like it because it requires an additional 
function call at the top of frequently called operations... However I'm 
not a huge fan of the head state array either, since it will require 
either pointer duplication, or pointer acrobatics, or the same helper 
function to get the card state.

A third option would be to use the console index as a parameter to each 
HwOp. graphic_console_init and QemuConsole could remain unchanged, as 
could all the graphic_hw_*() helpers. If the HwOp needs the QemuConsole 
for any given operation, it could then use 
qemu_console_lookup_by_index(). Many operations would only need the 
index though.

> cheers,
>    Gerd
>
>
>

  reply	other threads:[~2013-11-19 14:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-05 20:42 [Qemu-devel] Multi-head support RFC John Baboval
2013-11-06  1:46 ` Dave Airlie
2013-11-06 10:57   ` Gerd Hoffmann
2013-11-06 23:44     ` Dave Airlie
2013-11-07 13:00       ` Gerd Hoffmann
2013-11-08 15:20       ` John Baboval
2013-11-06 15:48   ` John Baboval
2013-11-06 10:55 ` Gerd Hoffmann
2013-11-06 15:39   ` John Baboval
2013-11-07 13:46     ` Gerd Hoffmann
2013-11-07 15:54       ` John Baboval
2013-11-15 20:14         ` John Baboval
2013-11-19  6:57           ` Gerd Hoffmann
2013-11-19 14:17             ` John Baboval [this message]
2013-11-20  7:39               ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=528B72E8.6070307@spineless.org \
    --to=baboval@spineless.org \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.