On 27-04-2012 20:14, Crístian Viana wrote:
On 27-04-2012 18:23, Peter Maydell wrote:
That appears to contain one of your older versions of this patch, not
v3. (It touches bsd-user/main.c, for example.) -- PMM
You were right, it was an older version. Now the branch is updated and
rebased agains
On 27-04-2012 18:23, Peter Maydell wrote:
That appears to contain one of your older versions of this patch, not
v3. (It touches bsd-user/main.c, for example.) -- PMM
You were right, it was an older version. Now the branch is updated and
rebased against the current master.
Best regards,
Crísti
On 27 April 2012 22:16, Crístian Viana wrote:
> On 27-04-2012 14:41, Anthony Liguori wrote:
>>
>> Can you post a git tree on github so I can look at the difference? Maybe
>> patch applied it wrong.
>
> git://github.com/cd1/qemu.git, branch qemu-version
That appears to contain one of your older v
On 27-04-2012 14:41, Anthony Liguori wrote:
Can you post a git tree on github so I can look at the difference?
Maybe patch applied it wrong.
git://github.com/cd1/qemu.git, branch qemu-version
Best regards,
Crístian.
On 04/27/2012 12:16 PM, Crístian Viana wrote:
On 25-04-2012 16:16, Anthony Liguori wrote:
If you run:
x86_64-softmmu/qemu-system-x86_64
This will SEGV because machine == NULL. It's quite a bit later in this
function when machine gets initialized with the default machine.
You mean running onl
On 25-04-2012 16:16, Anthony Liguori wrote:
If you run:
x86_64-softmmu/qemu-system-x86_64
This will SEGV because machine == NULL. It's quite a bit later in
this function when machine gets initialized with the default machine.
You mean running only the binary, without arguments? I got no SEG
On 04/13/2012 02:16 PM, Crístian Viana wrote:
Based on the following conversation:
http://mid.gmane.org/4f69f05b.5010...@codemonkey.ws
Which reminds me - qemu sticks the release version in
guest visible places like CPU version.
This is wrong and causes windows guests to print messages
about dr
On 13-04-2012 22:27, Peter Maydell wrote:
Why 32 ?
In that case, 32 was a estimative I made of the number of characters
that the VERSION string would have based on its original value ("qemu
usb-redir guest " QEMU_VERSION), so the new value wouldn't be much
longer than the original one. I don't
On 13 April 2012 20:59, Crístian Viana wrote:
>> If so, then you have a bug in
>> nseries.c: sprintf() is asking for a buffer overflow. Remember,
>> QEMU_VERSION has a compile-time fixed length, but if qemu_get_version()
>> is an arbitrary user string, you no longer have a guarantee that you fit
On 13 April 2012 20:16, Crístian Viana wrote:
> --- a/hw/usb/redirect.c
> +++ b/hw/usb/redirect.c
> @@ -141,8 +141,6 @@ static void usbredir_interrupt_packet(void *priv,
> uint32_t id,
> static int usbredir_handle_status(USBRedirDevice *dev,
> int status, i
On 13-04-2012 16:26, Eric Blake wrote:
> qemu_get_version returns whatever string got put there by
> qemu_set_version. Am I correct that the user has full control over the
> string passed to qemu_set_version?
Actually, this is not available to the user, the string passed to that
function is suppo
On 04/13/2012 01:16 PM, Crístian Viana wrote:
> Based on the following conversation:
>
> http://mid.gmane.org/4f69f05b.5010...@codemonkey.ws
>
>> Which reminds me - qemu sticks the release version in
>> guest visible places like CPU version.
>> This is wrong and causes windows guests to print mes
Based on the following conversation:
http://mid.gmane.org/4f69f05b.5010...@codemonkey.ws
> Which reminds me - qemu sticks the release version in
> guest visible places like CPU version.
> This is wrong and causes windows guests to print messages
> about driver updates when you switch.
> We should
13 matches
Mail list logo
