qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/6] gtk: add virtual console support


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 3/6] gtk: add virtual console support
Date: Sat, 25 Feb 2012 15:18:14 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

On 02/25/2012 02:22 PM, Stefan Weil wrote:
Am 25.02.2012 20:49, schrieb Anthony Liguori:
On 02/25/2012 10:21 AM, Stefan Weil wrote:
Am 20.02.2012 00:45, schrieb Anthony Liguori:
This enables VteTerminal to be used to render the text consoles. VteTerminal is
the same widget used by gnome-terminal which means it's VT100 emulation is as
good as they come.

It's also screen reader accessible, supports copy/paste, proper scrolling and
most of the other features you would expect from a terminal widget.

Signed-off-by: Anthony Liguori <address@hidden>
---
ui/gtk.c | 138 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 138 insertions(+), 0 deletions(-)

diff --git a/ui/gtk.c b/ui/gtk.c
index 502705b..bf65a4f 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
[...]
+static int gd_vc_handler(QemuOpts *opts, CharDriverState **chrp)
+{
+ CharDriverState *chr;
+
+ chr = g_malloc0(sizeof(*chr));

Some time ago, there was a decision to prefer g_new / g_new0:

I'm not sure where the book of decisions is kept, but I certainly don't agree.
a = malloc(sizeof(*a)) is an incredibly common pattern in QEMU.

It would be silly to change this pattern without good cause.

Regards,

Anthony Liguori

Hi Anthony,

there is no book of decisions for QEMU, but there is best practice.
As far as I remember this topic was first discussed in this
qemu-devel thread:

http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg01988.html

a = malloc(sizeof(*a)) is no longer a valid pattern for QEMU
since you introduced glib-2.0. Those calls were converted
to a = g_malloc(sizeof(*a)) which was reasonable for a simple
automated code conversion.

I also used the g_malloc pattern in my patch, but was convinced
that glib-2.0 offers a better alternative using g_new.

I meant g_malloc of course.

If we want to have a "best practice", we should document it in CODING_STYLE. But I wouldn't agree with such a patch to coding style anyway.

Regards,

Anthony Liguori


Kind regards,

Stefan Weil






reply via email to

[Prev in Thread] Current Thread [Next in Thread]