[Top][All Lists]

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

Re: [Qemu-trivial] [PATCH] srp: Don't use QEMU_PACKED for single element

From: Stefan Weil
Subject: Re: [Qemu-trivial] [PATCH] srp: Don't use QEMU_PACKED for single elements of a structured type
Date: Wed, 15 Aug 2012 17:59:26 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0

Am 15.08.2012 16:16, schrieb Stefan Hajnoczi:
On Fri, Aug 10, 2012 at 10:03:27PM +0200, Stefan Weil wrote:
QEMU_PACKED results in a MinGW compiler warning when it is
used for single structure elements:

warning: 'gcc_struct' attribute ignored

Using QEMU_PACKED for the whole structure avoids the compiler warning
without changing the memory layout.
Quick link for other reviewers:

Signed-off-by: Stefan Weil <address@hidden>
  hw/srp.h |    8 ++++----
  1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/srp.h b/hw/srp.h
index 3009bd5..5e0cad5 100644
--- a/hw/srp.h
+++ b/hw/srp.h
@@ -177,13 +177,13 @@ struct srp_tsk_mgmt {
      uint8_t    reserved1[6];
      uint64_t   tag;
      uint8_t    reserved2[4];
-    uint64_t   lun QEMU_PACKED;
+    uint64_t   lun;
      uint8_t    reserved3[2];
      uint8_t    tsk_mgmt_func;
      uint8_t    reserved4;
      uint64_t   task_tag;
      uint8_t    reserved5[8];
Here I actually see a difference for the uint64_t task_tag field.
Previously it was not packed, now it is packed and because it has 4 *
uint8_t before it there will be a difference in layout.

Looking at how QEMU accesses srp_tsk_mgmt, I think we're safe because we
never actually access task_tag?

Ben: Any thoughts on this patch?


4 * uint8_t + 4 bytes from the packed lun, so there is no change
for task_tag, it's always on a 8 byte boundary!


reply via email to

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