Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On Thu, Mar 25, 2010 at 03:07:20PM +, Daniel P. Berrange wrote: > I agree apps shouldn't use it for RPC, but admins using the interactive user > monitor are just as deserving of stable commands & args. I think, once QMP is completely there, admins would be better using a qemu-cmd that's just serialise it's command line arguments into a JSON command. (something like dbus-send for dbus). -- Vincent
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On Thu, Mar 25, 2010 at 01:59:22PM +, Daniel P. Berrange wrote: > > From my point of view, i wouldn't want to write a high level management > > toolstack in C, specially > > since the API is well defined JSON which is easily available in all high > > level language out there. > > It was pretty straightforward for libvirt to talk to the JSON protocol > from C using the YAJL library, so I don't think it is all that much of > a barrier for low level languages like C either. note, that it's not the talking JSON part that's difficult to do in C (it's just midly annoying compare to a highlevel language), but all the other part of a toolstack. Since there's no performance requirements, writing in C is just a bit of a waste ot time, but that's up to the developpers to choose the tools he wants, even if it's not the most appropriate one ;) > If we want to make life easy for app/library developers working against QEMU, > then the far more important aspect is to guarentee stability of all the QEMU > interfaces since that is where all the serious pain occurs over time. if you're talking about the QMP interface then I agree with you. This need to be back/forward compatible as much as possible and stable. the other interface (i.e. the user monitor) has no business beeing backward-compatible though, since it should never be used to talk a RPC. -- Vincent
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On Thu, Mar 25, 2010 at 08:57:36AM -0500, Anthony Liguori wrote: > Why? > > We can provide a generic QMP dispatch interface that high level > languages can use. Then they can do fancy dispatch, treat QErrors as > exceptions, etc. Because more than likely it will be more efforts than doing the same work in the native language, forcing certains designs [1] up to high-level-language developers throats, and possibly less stability (segfault, memory corruption, memory leak, ..) specially in development phase. [1] lack of separation between IO and pure functions, file descriptor versus stream, C memory functions instead of GC based, and probably lots of other things easily accessible from high level language. -- Vincent
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 24/03/10 21:40, Anthony Liguori wrote: If so, what C clients you expected beyond libvirt? Users want a C API. I don't agree that libvirt is the only C interface consumer out there. (I've seen this written too many times ...) How do you know that ? did you do a poll or something where *actual* users vote/tell ? From my point of view, i wouldn't want to write a high level management toolstack in C, specially since the API is well defined JSON which is easily available in all high level language out there. -- Vincent
Re: [Qemu-devel] Re: [PATCH] Add VirtIO Frame Buffer Support
On Tue, Nov 03, 2009 at 11:38:18AM +0200, Avi Kivity wrote: > On 11/03/2009 01:25 PM, Vincent Hanquez wrote: >> not sure if i'm missing the point here, but couldn't it be hypothetically >> extended to stuff 3d (or video& more 2d accel ?) commands too ? I can't >> imagine the cirrus or stdvga driver be able to do that ever ;) >> > > cirrus has pretty good 2d acceleration. 3D is a mega-project though. absolutely huge indeed, but still alexander's code is pretty much the only way, to start such a project. with maybe added benefits on more and easier 2d acceleration. or otherwise wait for SR-IOV graphics cards (or similar tech)... -- Vincent
Re: [Qemu-devel] Re: [PATCH] Add VirtIO Frame Buffer Support
On Tue, Nov 03, 2009 at 07:39:34AM +0100, Alexander Graf wrote: > > On 03.11.2009, at 07:34, Avi Kivity wrote: > >> On 11/03/2009 08:27 AM, Alexander Graf wrote: >>> How does it work today? >>> >>> You boot into a TERM=dumb line based emulation on 3270 (worst thing >>> haunting people's nightmares ever), trying to get out of that mode >>> as quickly as possible and off into SSH / VNC. >> >> Despite the coolness factor, IMO a few minutes during install time do >> not justify a new hardware model and a new driver. > > It's more than just coolness factor. There are use cases out there > (www.susestudio.com) that don't want to rely on the guest exporting a VNC > server to the outside just to access graphics. You also want to see boot > messages, have a console login screen, be able to debug things without > switching between virtio-console and vnc, etc. etc. > > The hardware model isn't exactly new either. It's just the next logical > step to a full PV machine using virtio. If the virtio-fb stuff turns out > to be really fast and reliable, I could even imagine it being the default > target for kvm on ppc as well, as we can't switch resolutions on the fly > there atm. not sure if i'm missing the point here, but couldn't it be hypothetically extended to stuff 3d (or video & more 2d accel ?) commands too ? I can't imagine the cirrus or stdvga driver be able to do that ever ;) -- Vincent
Re: [Qemu-devel] QJSON status?
On Fri, Oct 30, 2009 at 05:51:20PM +0100, Paolo Bonzini wrote: > I'm a bit lost on the QJSON patches that were posted and what's missing > yet... Anthony, can you place them in your queue or in a separate > branch? a bit OOT by now, but my libjson parser/printer is available at http://projects.snarc.org/libjson/ -- Vincent
Re: [Qemu-devel] Re: [RFC 0/7] QError v1
On Fri, Oct 30, 2009 at 06:33:15PM +0100, Paolo Bonzini wrote: > On 10/30/2009 06:15 PM, Daniel P. Berrange wrote: >> If we're going to use JSON we should be 100% compliant with the JSON >> spec, not extend it. By adding custom QEMU extensions, we loose the >> ability for programming language to trivially talk to QEMU using a >> standard JSON parser, and instead everyone has to write custom client >> side code yet again. > > The single-quoted-string extension is just to be used internally to ease > writing JSON templates in C. All emitted text will go through the JSON > encoder, which will be conservative (no extensions) for the reasons you > mention. Are you going to have a mechanism to turn off the extension when the parser is parsing from external source then ? because otherwise it means that qemu is accepting a superset of JSON; so how long before client start by mistake doing the same thing instead of using conformant JSON ? I really can't imagine where typing \"..\" instead of '..' for a couple of strings (10, 30 at most ?) make this single quote string a necessity. -- Vincent
Re: [Qemu-devel] Re: [PATCH 01/10] Introduce qmisc module
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 talking about ?) which strikes me as invalid JSON. -- Vincent
Re: [Qemu-devel] Re: [PATCH 01/10] Introduce qmisc module
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 values (string, int, float, null, true, false) as a char * + length. for exactly the same reason, integration with glib would take the same 50 lines "effort". No lines is a lot better than 50. :) well it all depends on how you see thing; whilst i'm happy to help all sort of integration (qemu in this case), my library has been made for integrating with absolutely any object model. so 50 lines seems like a win to me, because I could do the same thing on a project that use glib, or some QT model using exactly the same engine. Hence the reason why i'm packaging it as a .a/.so library. (not that I particularly object to an embedded use case too). I think that's a win in the end when people can just reuse wheels instead of designing new one for catering for special needs. The real problem though is that the parsers I looked at had their own "object model", some of them are quite simple others are more sophisticated than QObject. Making no use of any kind of intermediate representation like this is a feature, as things get simpler. Also, don't get me wrong, but if we would consider your parser we would have to consider the others two or three that are listed in json.org and have a compatible license. most of the parser there are either, weirdly licensed, have an object model integrated with it, are not interruptible, or are quite complex for no apparent reason; I carefully read all of them, before choosing to reimplement one from scratch. -- Vincent
Re: [Qemu-devel] Re: [PATCH 01/10] Introduce qmisc module
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 callback for every values (string, int, float, null, true, false) as a char * + length. for exactly the same reason, integration with glib would take the same 50 lines "effort". note that FTR, obviously i'ld like to have my library used, but i'm happy that any library that is *fully* JSON compliant is used (no extensions however since you're obviously loosing the benefit of using JSON if you create extensions). We need two sets of extensions for use within qemu. Single quoted strings and varargs support. While single quoted strings would be easy to add to any library, vararg support is a bit more tricky as you need to carefully consider where you pop from the varargs list. A simple sprintf() isn't sufficient for embedding QObjects. care to explain what's a single quoted string and varargs support means in your context ? (just a simple example you do maybe ?) When generating on-the-wire response traffic, we shouldn't use any of the extensions so it will be 100% json.org compliant. great. I'm pretty sure if you tried to duplicate the functionality of my patches, it would be much more than 50 lines. That's not saying it's a better json parser, just that we're looking for very particular features from it. Since it doesn't appears to be linked to json particularly, I don't understand why it's a feature of the parser though.. and then any parser could grow the support you need on top of the parser couldn't they ? -- Vincent
Re: [Qemu-devel] Re: [PATCH 01/10] Introduce qmisc module
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 functions, and callback for integer/float doesn't have their data converted automatically which means that the user of the library can use whatever it want to support the non-limited size JSON number (or just return errors for user that want the limit). the library by itself is 39K with -g last time i've looked. Integration with QObjects is a killer feature, I think it's the stronger argument against grabbing one from the internet. 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 values (string, int, float, null, true, false) as a char * + length. for exactly the same reason, integration with glib would take the same 50 lines "effort". note that FTR, obviously i'ld like to have my library used, but i'm happy that any library that is *fully* JSON compliant is used (no extensions however since you're obviously loosing the benefit of using JSON if you create extensions). -- Vincent
Re: [Qemu-devel] Re: [PATCH 01/10] Introduce qmisc module
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 I didn't notice a couple of hours ago). This one is ~5% slower than the "Evil" one, but half the size. Tested against the comments.json file from the "Evil" parser and with valgrind too. Does all the funky Unicode stuff too. I haven't benchmarked mine. While yours came out an hour earlier, I included a full test suite, output QObjects, and support vararg parsing so I think I win :-) ar.. got mine too, i've been doing for the last 3 weeks slowly; 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 functions, and callback for integer/float doesn't have their data converted automatically which means that the user of the library can use whatever it want to support the non-limited size JSON number (or just return errors for user that want the limit). the library by itself is 39K with -g last time i've looked. also the library comes with a jsonlint binary that's equivalent to xmllint (well formatting and verification). I'll package thing up and post a link to it on monday. -- Vincent
