Hello community,

here is the log from the commit of package qemu for openSUSE:Factory checked in 
at 2012-08-26 11:34:19
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/qemu (Old)
 and      /work/SRC/openSUSE:Factory/.qemu.new (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Package is "qemu", Maintainer is "[email protected]"

Changes:
--------
--- /work/SRC/openSUSE:Factory/qemu/qemu.changes        2012-07-22 
15:21:31.000000000 +0200
+++ /work/SRC/openSUSE:Factory/.qemu.new/qemu.changes   2012-08-26 
11:34:23.000000000 +0200
@@ -1,0 +2,6 @@
+Tue Jul 31 09:50:25 UTC 2012 - [email protected]
+
+- add hijack for /proc/cpuinfo
+- add compatibility patch for glibc 2.16 (Thanks AJ!)
+
+-------------------------------------------------------------------

New:
----
  0029-linux-user-Fake-proc-cpuinfo.patch.patch
  0030-Replace-struct-siginfo-with-siginfo.patch

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Other differences:
------------------
++++++ qemu.spec ++++++
--- /var/tmp/diff_new_pack.06v7zt/_old  2012-08-26 11:34:25.000000000 +0200
+++ /var/tmp/diff_new_pack.06v7zt/_new  2012-08-26 11:34:25.000000000 +0200
@@ -52,6 +52,8 @@
 Patch0026:      0026-linux-user-Run-multi-threaded-code-.patch
 Patch0027:      0027-linux-user-lock-tb-flushing-too.pat.patch
 Patch0028:      0028-XXX-merge-with-segmentation-fault-p.patch
+Patch0029:      0029-linux-user-Fake-proc-cpuinfo.patch.patch
+Patch0030:      0030-Replace-struct-siginfo-with-siginfo.patch
 # this is to make lint happy
 Source300:      rpmlintrc
 Source302:      bridge.conf
@@ -187,6 +189,8 @@
 %patch0026 -p1
 %patch0027 -p1
 %patch0028 -p1
+%patch0029 -p1
+%patch0030 -p1
 
 %build
 # build QEMU

++++++ 0029-linux-user-Fake-proc-cpuinfo.patch.patch ++++++
>From 63697bbdfd6ccede902ce09cb0c4f860e0fdf099 Mon Sep 17 00:00:00 2001
From: Alexander Graf <[email protected]>
Date: Mon, 23 Jul 2012 10:24:14 +0200
Subject: [PATCH] linux-user: Fake /proc/cpuinfo

Fedora 17 for ARM reads /proc/cpuinfo and fails if it doesn't contain
ARM related contents. This patch implements a quick hack to expose real
/proc/cpuinfo data taken from a real world machine.

The real fix would be to generate at least the flags automatically based
on the selected CPU. Please do not submit this patch upstream until this
has happened.

Signed-off-by: Alexander Graf <[email protected]>
---
 linux-user/syscall.c |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index b0566cd..2efd7f4 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -4980,6 +4980,25 @@ static int open_self_stat(void *cpu_env, int fd)
     return 0;
 }
 
+static int open_cpuinfo(void *cpu_env, int fd)
+{
+    dprintf(fd,
+"Processor       : ARMv7 Processor rev 5 (v7l)\n"
+"BogoMIPS        : 799.53\n"
+"Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3\n"
+"CPU implementer : 0x41\n"
+"CPU architecture: 7\n"
+"CPU variant     : 0x2\n"
+"CPU part        : 0xc08\n"
+"CPU revision    : 5\n"
+"\n"
+"Hardware        : Genesi Efika MX (Smarttop)\n"
+"Revision        : 51030\n"
+"Serial          : 0000000000000000\n");
+
+    return 0;
+}
+
 static int open_self_auxv(void *cpu_env, int fd)
 {
     TaskState *ts = ((CPUArchState *)cpu_env)->opaque;
@@ -5020,6 +5039,7 @@ static int do_open(void *cpu_env, const char *pathname, 
int flags, mode_t mode)
         { "/proc/self/maps", open_self_maps },
         { "/proc/self/stat", open_self_stat },
         { "/proc/self/auxv", open_self_auxv },
+        { "/proc/cpuinfo", open_cpuinfo },
         { NULL, NULL }
     };
 
++++++ 0030-Replace-struct-siginfo-with-siginfo.patch ++++++
>From 3ff16f3f6b220d13caeb068a865c82675da802ba Mon Sep 17 00:00:00 2001
From: Richard W.M. Jones <[email protected]>
Date: Thu, 5 Jul 2012 03:32:44 +0000
Subject: [PATCH] Replace 'struct siginfo' with 'siginfo_t'.

glibc 2.16 will remove the undocumented definition of 'struct siginfo'
from <bits/siginfo.h>.

This change is already present in glibc 2.15.90, so qemu compilation
of certain targets (eg. cris-user) breaks.

This struct was always typedef'd to be the same as 'siginfo_t' which
is what POSIX documents, so use that instead.

Signed-off-by: Richard W.M. Jones <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
---
 linux-user/signal.c |    8 ++++----
 user-exec.c         |    2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index c00cf75..f33ea70 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2877,7 +2877,7 @@ static void setup_rt_frame(int sig, struct 
target_sigaction *ka,
     * Arguments to signal handler:
     *
     *   a0 = signal number
-    *   a1 = pointer to struct siginfo
+    *   a1 = pointer to siginfo_t
     *   a2 = pointer to struct ucontext
     *
     * $25 and PC point to the signal handler, $29 points to the
@@ -3283,7 +3283,7 @@ struct target_signal_frame {
 };
 
 struct rt_signal_frame {
-    struct siginfo info;
+    siginfo_t info;
     struct ucontext uc;
     uint32_t tramp[2];
 };
@@ -3502,9 +3502,9 @@ struct target_signal_frame {
 };
 
 struct rt_signal_frame {
-        struct siginfo *pinfo;
+        siginfo_t *pinfo;
         void *puc;
-        struct siginfo info;
+        siginfo_t info;
         struct ucontext uc;
         uint8_t retcode[8];       /* Trampoline code. */
 };
diff --git a/user-exec.c b/user-exec.c
index cc57bde..2d7f6c9 100644
--- a/user-exec.c
+++ b/user-exec.c
@@ -599,7 +599,7 @@ int cpu_signal_handler(int host_signum, void *pinfo,
 int cpu_signal_handler(int host_signum, void *pinfo,
                        void *puc)
 {
-    struct siginfo *info = pinfo;
+    siginfo_t *info = pinfo;
     struct ucontext *uc = puc;
     unsigned long pc = uc->uc_mcontext.sc_iaoq[0];
     uint32_t insn = *(uint32_t *)pc;
-- 
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to