On Mon, Oct 19, 2009 at 8:23 AM, wrote:
>
> I think I have a couple of other fixes and patches on top of that as
> well, but I'd rather wait until you get this bunch committed and then
> format the patches against the new mainline so that they apply.
It's already been committed (the commit notif
>> Apart from the points you have raised about specific patches there
>> were few more minor bugs in the series spotted by Juha Riihimäki
>> . A fix is available at
>> http://repo.or.cz/w/qemu/navara.git?a=commit;h=2ce696baa6fc5d99522cf387b6a4913807fd43ed
>
> One of the fix was already in my branch
On Sat, 17 Oct 2009 08:36:02 -0500
Anthony Liguori wrote:
> qfloat is a qobject wrapper for double precision floating points
>
> Signed-off-by: Anthony Liguori
> ---
> Makefile |3 +-
> qfloat.c | 76
> +
> qfloat.h | 29 +
On Sun, 18 Oct 2009 11:32:11 -0500
Anthony Liguori wrote:
> Luiz Capitulino wrote:
> > Okay, I just took a quick look at them and am looking at Anthony's
> > right now.
> >
> > Anyway, my brainstorm on this would be to have to_string() and have
> > default methods on all types to return a simpl
On Sat, 17 Oct 2009 08:36:06 -0500
Anthony Liguori wrote:
> We currently model as json bool as an int. This works fine on the server side
> but it means we cannot send back proper bools to the client. Introducing a
> proper QBool type fixes that.
As we talked earlier today, I think it would b
On Sat, 17 Oct 2009 08:36:01 -0500
Anthony Liguori wrote:
> This allows qstring to be used for dynamic string construction.
>
> Signed-off-by: Anthony Liguori
> ---
> qstring.c | 37 -
> qstring.h |4
> 2 files changed, 40 insertions(+), 1 deletio
On Sat, 17 Oct 2009 08:36:00 -0500
Anthony Liguori wrote:
> I fat-fingered the git send-email command the first time so here's the second
> iteration.
Got it now..
> This series introduces a json parsing framework. The parser is a recursive
> decent parser and implements the full json spec ex
On Sun, Oct 18, 2009 at 12:32 PM, Vincent Hanquez wrote:
> Anthony Liguori wrote:
>>
>> Here's a first pass. I'll clean up this afternoon and post a proper
>> patch. It turned out to work pretty well.
>
> It doesn't seems to validate anything ?? or is it just a lexer ?
That's just a lexer. I p
y bit for the x86 target before but the sign of the returned errno
> > was still wrong), and I finally fixed the if (1) above (made bsd_type
> > global.)
> >
> > And, I now can run FreeBSD/amd64 /bin/sh and vim on same! :) (zsh
> > not yet tho.)
> >
> > Oh and Toni tested taking FreeBSD/i386's default linker script,
> > changing only the load address to 0x6000 as in qemu's and,
> > using that as i386.ld, he now can run qemu-i386 on FreeBSD/i386 with
> > simple executables too... See files/patch-bsd-user-ld in the shar,
> > which I also now moved the x86_64.ld patch to that I had talked about
> > earlier. It probably can't be used everywhere as is tho since it has:
> > OUTPUT_FORMAT("elf32-i386-freebsd", "elf32-i386-freebsd",
> > "elf32-i386-freebsd")
> > (and I also don't know if the one currently in the tree has other
> > features that are needed at least on Linux, any linker gurus care
> > to comment?)
> >
> > Here is the rest of the bsd-user patches again (files/patch-bsd-user
> > in the shar), if you think they are ready to commit I'm not against it
> > anymore :), comments are also welcome of course.
>
> Thanks, applied. I made up a short commit message.
Sorry, my fault, I should have supplied a `proper' one... :/
(sysarch(2) and errno were only the things I fixed since the last
iteration, I guess its too late to add the rest now?)
In other news... I have made another port update from today's git:
http://people.freebsd.org/~nox/qemu/qemu-devel-20091018.patch
resp.
http://people.freebsd.org/~nox/qemu/qemu-devel-20091018.shar
Enjoy,
Juergen
On Sat, Oct 17, 2009 at 1:34 AM, Juergen Lock wrote:
> On Wed, Oct 14, 2009 at 12:19:32AM +0200, Juergen Lock wrote:
>> On Tue, Oct 13, 2009 at 12:20:58AM +0200, Juergen Lock wrote:
>> > On Mon, Oct 12, 2009 at 10:55:24PM +0300, Blue Swirl wrote:
>> > > On Mon, Oct 12, 2009 at 1:18 AM, Juergen Loc
On 10/18/2009 06:32 PM, Anthony Liguori wrote:
What's the value of integrating into the objects verses having a
separate function that can apply it to the objects?
That's just different style. Of course you could do a
switch(qobject_type(qobject)) instead of using polymorphism. It would
be
On 10/18/2009 06:46 PM, Vincent Hanquez wrote:
care to explain what's a single quoted string and varargs support means
in your context ? (just a simple example you do maybe ?)
single-quoted string: Being able to parse 'name' in addition to "name",
which is convenient because in C the latter wo
Anthony Liguori wrote:
Here's a first pass. I'll clean up this afternoon and post a proper
patch. It turned out to work pretty well.
It doesn't seems to validate anything ?? or is it just a lexer ?
you're also including ' as a string escape value (is that the single
quote thing you were talki
Luiz Capitulino wrote:
I can't think of any reason why integration with qobject would take more
than 50 lines of C on the user side of the library.
since the API is completely SAX like (i call it SAJ for obvious reason),
you get callback entering/leaving object/array
and callback for every value
Anthony Liguori wrote:
Vincent Hanquez wrote:
I can't think of any reason why integration with qobject would take
more than 50 lines of C on the user side of the library.
since the API is completely SAX like (i call it SAJ for obvious
reason), you get callback entering/leaving object/array
and
This basically fixes build with -static against recent glibc (libc.a's
__libc_csu_init() refers to these symbols).
---
i386.ld |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/i386.ld b/i386.ld
index f2dafec..9b4063e 100644
--- a/i386.ld
+++ b/i386.ld
@@ -39,7 +39,13
Luiz Capitulino wrote:
Okay, I just took a quick look at them and am looking at Anthony's
right now.
Anyway, my brainstorm on this would be to have to_string() and have
default methods on all types to return a simple string representation.
What's the value of integrating into the objects
Vincent Hanquez wrote:
I can't think of any reason why integration with qobject would take
more than 50 lines of C on the user side of the library.
since the API is completely SAX like (i call it SAJ for obvious
reason), you get callback entering/leaving object/array
and callback for every value
Anthony Liguori wrote:
Paolo Bonzini wrote:
On 10/18/2009 04:06 PM, Luiz Capitulino wrote:
Integration with QObjects is a killer feature, I think it's the
stronger argument against grabbing one from the internet.
Yeah, I'd say let's go with Anthony's stuff. I'll rebase the encoder
on top
IMO, it would be faster if we provide keyboard shortcuts that will
stop and resume VM execution right from SDL guest interface, rather
than switching to console monitor first and type "s" or "c"
respectively.
Note: I simply skip checking the keys in encrypted block devices when
resuming the VM. No
On Sun, 18 Oct 2009 17:25:47 +0200
Paolo Bonzini wrote:
>
> >> I'd strongly suggest making the JSON encoder live outside of QObject.
> >> There are many possible ways to represent a QObject. Think of JSON as a
> >> view of the QObject model. The human monitor mode representation is a
> >> diff
On 10/18/2009 05:35 PM, Luiz Capitulino wrote:
(no
extensions however since you're obviously loosing the benefit of using
JSON if you create extensions).
This is already settled, I hope.
I think he's referring to things such as putting things such as
single-quoted strings, or % escapes fo
On Sun, 18 Oct 2009 16:06:29 +0100
Vincent Hanquez wrote:
> Luiz Capitulino wrote:
> >> it got a raw/pretty printer, an interruptible parser (on the same idea
> >> as JSON_parser.c), it's faster than JSON_parser.c [1],
> >> it's completely generic (more like a library than an embedded thing),
>
I'd strongly suggest making the JSON encoder live outside of QObject.
There are many possible ways to represent a QObject. Think of JSON as a
view of the QObject model. The human monitor mode representation is a
different view.
My rationale was that since QObject is tailored over JSON, we mi
On Sun, 18 Oct 2009 09:49:55 -0500
Anthony Liguori wrote:
> Paolo Bonzini wrote:
> > On 10/18/2009 04:06 PM, Luiz Capitulino wrote:
> >> Integration with QObjects is a killer feature, I think it's the
> >> stronger argument against grabbing one from the internet.
> >
> > Yeah, I'd say let's go
Luiz Capitulino wrote:
it got a raw/pretty printer, an interruptible parser (on the same idea
as JSON_parser.c), it's faster than JSON_parser.c [1],
it's completely generic (more like a library than an embedded thing),
fully JSON compliant (got a test suite too), support
user supplied alloc func
Paolo Bonzini wrote:
On 10/18/2009 04:06 PM, Luiz Capitulino wrote:
Integration with QObjects is a killer feature, I think it's the
stronger argument against grabbing one from the internet.
Yeah, I'd say let's go with Anthony's stuff. I'll rebase the encoder
on top of it soonish (I still t
On Thu, Oct 15, 2009 at 11:51 PM, Aurelien Jarno wrote:
> Signed-off-by: Aurelien Jarno
> ---
> target-arm/translate.c | 4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/target-arm/translate.c b/target-arm/translate.c
> index 0c10ac2..bb0f8ef 100644
> --- a/target-a
On Thu, Oct 15, 2009 at 11:08 PM, Aurelien Jarno wrote:
> (INT32_MIN / -1) triggers an overflow, and the result depends on the
> host architecture (INT32_MIN on arm, -1 on ppc, SIGFPE on x86). Use a
> test to output the correct value.
>
> Signed-off-by: Aurelien Jarno
> ---
> target-arm/helper.c
On Thu, Oct 15, 2009 at 11:14 PM, Aurelien Jarno wrote:
> Signed-off-by: Aurelien Jarno
> ---
> target-arm/helper.c | 6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index 701629a..656b5df 100644
> --- a/target-arm/help
On 10/18/2009 04:06 PM, Luiz Capitulino wrote:
Integration with QObjects is a killer feature, I think it's the
stronger argument against grabbing one from the internet.
Yeah, I'd say let's go with Anthony's stuff. I'll rebase the encoder on
top of it soonish (I still think it's best if JSON
On Sat, 17 Oct 2009 11:01:33 +0100
Vincent Hanquez wrote:
> Anthony Liguori wrote:
> > Paolo Bonzini wrote:
> >> On 10/16/2009 11:37 PM, Anthony Liguori wrote:
> >>>
> >>> I already am :-) Stay tuned, I should have a patch later this
> >>> afternoon.
> >>
> >> Was it a race? (Seriously, sorry
On 10/18/2009 06:25 AM, Jamie Lokier wrote:
The manual for GNU gettext explains quite well why gettext takes a
message string as argument, instead of a "message code". Imho, a
similar case can be made for error messages at call sites.
That's true. However here we have the case of having error
On Sun, Oct 18, 2009 at 5:09 AM, Jamie Lokier wrote:
[...]
>
> Please don't do that. Some code traces instructions through the
> vsyscall/vdso page, and will be surprised if a syscall instruction
> does not do what's expected based on the registers at that point.
>
> Also I don't know if anyone's
On Sun, Oct 18, 2009 at 4:47 AM, Jamie Lokier wrote:
> Laurent Desnogues wrote:
>> A recent compiler (gcc 4.4.0) produces this code for a statically
>> compiled program:
>>
>> 005779e0 :
>> 5779e0: 48 83 ec 08 sub $0x8,%rsp
>> 5779e4: 48 c7 c0 00 04 60 ff mov
On Thu, Oct 15, 2009 at 05:48:19PM +0200, Michael S. Tsirkin wrote:
> On Thu, Oct 15, 2009 at 10:18:18AM -0500, Anthony Liguori wrote:
> > Michael S. Tsirkin wrote:
> >> On Thu, Oct 15, 2009 at 08:32:03AM -0500, Anthony Liguori wrote:
> >>
> >>> Michael S. Tsirkin wrote:
> >>>
> On Wed
On Sun, Oct 18, 2009 at 04:09:44AM +0100, Jamie Lokier wrote:
> Edgar E. Iglesias wrote:
> > Did you consider having the linux-user loader pass a qemu version of the
> > x86_64 vdso to the guest through the auxvector? That version could probably
> > implement the vsyscalls by translating them into
37 matches
Mail list logo
