All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mitsyanko Igor <i.mitsyanko@samsung.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: e.voevodin@samsung.com, quintela@redhat.com,
	qemu-devel@nongnu.org, kyungmin.park@samsung.com,
	d.solodkiy@samsung.com, m.kozlov@samsung.com, afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH 0/5] VMState cleanups
Date: Wed, 22 Feb 2012 16:01:00 +0400	[thread overview]
Message-ID: <4F44D8FC.80006@samsung.com> (raw)
In-Reply-To: <CAFEAcA9+7mvx7saRbJ4ygSExi4DT4ykz-r=FLEtxEa5zvEyJvw@mail.gmail.com>

On 02/22/2012 03:26 PM, Peter Maydell wrote:
> On 22 February 2012 10:15, Igor Mitsyanko<i.mitsyanko@samsung.com>  wrote:
>> This patchset cleans up and optimizes vmstate implementation.
>>
>> Patch 1 is a trivial bug fixing.
>> Patches 2 and 3 replaces target_phys_addr_t in pxa implementation
>> to uint32_t.
>> Patch 4 moves VMSTATE_UINTTL from hw.h to vmstate.h. Explicit dependency
>> on NEED_CPU_H is droped, I failed to understand why it was presented at all.
>
> So if we apply patches 1-3 (which all look plausible) then the only
> remaining user of VMSTATE_UINTTL is target-i386/machine.c as far as
> I can see.
>
> This leaves me wondering if we shouldn't just put it actually in
> target-i386/machine.c as a convenience macro for that specific CPU
> to avoid having to have more #ifdef TARGET_X86_64s. (I note that
> the machine.c code is already pretty inconsistent, eg lstar and
> cstar are defined as target_ulong and saved with VMSTATE_UINT64.)
>
> Basically VMSTATE_UINTTL seems like a bit of a dangerous thing to
> leave lying around as there aren't really very many use cases
> for it...

I personally don't really like all these "hack" VMSTATE macros spread 
all around QEMU code. I would prefer to have all convenient VMSTATE_*s 
in one place and eventually replace all file-specific hack macro with 
standard ones. Not sure that it's worth an effort though.
If we're going to move UINTTL* to target-i386/machine.c, then they 
probably should be implemented in the same way as they are implemented 
in hw.h now. But without NEED_CPU_H.

-- 
Mitsyanko Igor
ASWG, Moscow R&D center, Samsung Electronics
email: i.mitsyanko@samsung.com

  reply	other threads:[~2012-02-22 12:01 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-22 10:15 [Qemu-devel] [PATCH 0/5] VMState cleanups Igor Mitsyanko
2012-02-22 10:15 ` [Qemu-devel] [PATCH 1/5] target-alpha/machine.c: use VMSTATE_UINT64* instead of VMSTATE_UINTTL* Igor Mitsyanko
2012-02-22 11:19   ` Peter Maydell
2012-02-22 13:49   ` Juan Quintela
2012-02-22 10:15 ` [Qemu-devel] [PATCH 2/5] hw/pxa2xx_dma.c: drop VMSTATE_UINTTL usage Igor Mitsyanko
2012-02-22 11:06   ` Peter Maydell
2012-02-22 13:47   ` Juan Quintela
2012-02-22 13:52     ` Peter Maydell
2012-02-22 14:05       ` Juan Quintela
2012-02-22 10:15 ` [Qemu-devel] [PATCH 3/5] hw/pxa2xx_lcd.c: " Igor Mitsyanko
2012-02-22 11:07   ` Peter Maydell
2012-02-22 11:36   ` andrzej zaborowski
2012-02-22 12:00     ` Peter Maydell
2012-02-22 12:13       ` andrzej zaborowski
2012-02-22 12:48         ` Peter Maydell
2012-02-22 12:56           ` andrzej zaborowski
2012-02-22 13:32             ` Mitsyanko Igor
2012-02-22 13:56         ` Juan Quintela
2012-02-22 12:26     ` Mitsyanko Igor
2012-02-22 12:48       ` andrzej zaborowski
2012-02-22 13:30         ` Mitsyanko Igor
2012-02-22 10:15 ` [Qemu-devel] [PATCH 4/5] vmstate: refactor and move VMSTATE_UINTTL* macro Igor Mitsyanko
2012-02-22 14:00   ` Juan Quintela
2012-02-22 10:15 ` [Qemu-devel] [PATCH 5/5] vmstate: introduce get_bufsize entry in VMStateField Igor Mitsyanko
2012-02-22 11:26 ` [Qemu-devel] [PATCH 0/5] VMState cleanups Peter Maydell
2012-02-22 12:01   ` Mitsyanko Igor [this message]
2012-02-22 12:49   ` Andreas Färber
2012-02-22 12:50     ` Peter Maydell
2012-02-22 14:02   ` Juan Quintela
2012-02-22 15:37     ` Andreas Färber
2012-02-22 15:42       ` Peter Maydell
2012-02-22 16:04         ` Andreas Färber
2012-02-22 16:09           ` Peter Maydell
2012-02-22 23:41             ` Alexander Graf
2012-02-23 13:52               ` Juan Quintela
2012-02-22 12:06 ` Peter Maydell

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=4F44D8FC.80006@samsung.com \
    --to=i.mitsyanko@samsung.com \
    --cc=afaerber@suse.de \
    --cc=d.solodkiy@samsung.com \
    --cc=e.voevodin@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=m.kozlov@samsung.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /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.