qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	John Snow <jsnow@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: [Qemu-devel] [RFC] ide: Don't use qemu_hw_version() for firmware revision
Date: Wed, 11 Nov 2015 20:02:53 -0200	[thread overview]
Message-ID: <1447279373-5006-1-git-send-email-ehabkost@redhat.com> (raw)

The IDEState.version field is used for firmware version
information returned to the guest. Updating firmware information
on QEMU upgrade is supposed to be acceptable, so IDE doesn't need
the version compatibility magic of qemu_hw_version() and can use
QEMU_VERSION directly.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
I'm sending this just to start a discussion about what exactly we
are supposed to return to the guest on those IDE fields. Should
we return:

1) Something that never changes and don't reveal QEMU version
   information (e.g. "QEMU")?
2) Something that is always the same depending on the
   machine-type (machine-type name? MachineClass.hw_version?)
3) Something that change every time QEMU is upgraded (QEMU_VERSION)?
4) Something else?

This patch implements option (3).

---
 hw/ide/core.c     | 2 +-
 hw/ide/internal.h | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/ide/core.c b/hw/ide/core.c
index 364ba21..1602707 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -2312,7 +2312,7 @@ int ide_init_drive(IDEState *s, BlockBackend *blk, IDEDriveKind kind,
     if (version) {
         pstrcpy(s->version, sizeof(s->version), version);
     } else {
-        pstrcpy(s->version, sizeof(s->version), qemu_hw_version());
+        pstrcpy(s->version, sizeof(s->version), QEMU_VERSION);
     }
 
     ide_reset(s);
diff --git a/hw/ide/internal.h b/hw/ide/internal.h
index e4629b0..a4277ce 100644
--- a/hw/ide/internal.h
+++ b/hw/ide/internal.h
@@ -378,6 +378,7 @@ struct IDEState {
     /* set for lba48 access */
     uint8_t lba48;
     BlockBackend *blk;
+    /* Firmware revision/version */
     char version[9];
     /* ATAPI specific */
     struct unreported_events events;
@@ -488,6 +489,7 @@ struct IDEDevice {
     uint32_t unit;
     BlockConf conf;
     int chs_trans;
+    /* Firmware revision/version */
     char *version;
     char *serial;
     char *model;
-- 
2.1.0

             reply	other threads:[~2015-11-11 22:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-11 22:02 Eduardo Habkost [this message]
2015-11-12  8:27 ` [Qemu-devel] [RFC] ide: Don't use qemu_hw_version() for firmware revision Markus Armbruster
2015-11-12 15:19   ` Eduardo Habkost

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=1447279373-5006-1-git-send-email-ehabkost@redhat.com \
    --to=ehabkost@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).