From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49313 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q23qK-0003Fv-3Y for qemu-devel@nongnu.org; Tue, 22 Mar 2011 11:50:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q23qE-0002kE-GS for qemu-devel@nongnu.org; Tue, 22 Mar 2011 11:49:59 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:47675) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q23qE-0002k0-8C for qemu-devel@nongnu.org; Tue, 22 Mar 2011 11:49:54 -0400 Received: by yib19 with SMTP id 19so3558597yib.4 for ; Tue, 22 Mar 2011 08:49:52 -0700 (PDT) Message-ID: <4D88C516.30007@codemonkey.ws> Date: Tue, 22 Mar 2011 10:49:42 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] QCFG: a new mechanism to replace QemuOpts and option handling References: <4D7E5507.8010205@codemonkey.ws> <4D8252CD.4060607@codemonkey.ws> <4D83DF37.8060701@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , Chris Wright , qemu-devel , Stefan Hajnoczi , Adam Litke On 03/22/2011 08:01 AM, Markus Armbruster wrote: > Type checking macros are feasible (see [*] for an existence proof), but > things do get hairy, and the resulting error messages can be less than > clear at times. That just gives you a warning. You can do much better things with __builtin_types_compatible_p. But neither really solves the problem I'm talking about. I can go into it in depth but hopefully we both can agree that trying to build introspection macros is pretty difficult if not impossible :-) >> However, >> this makes it very difficult to support things like lists of lists or >> anything else that would basically require a non-concrete type. > Sounds like you want a more expressive type system than C's, and propose > to get it by building your own DSL. I'm not sure that's wise. It's an IDL. IDL based RPCs are pretty common with C. The IDL is purely declarative. >> If you plan to expose these types in a library, you need to either >> explicitly pad each structure and make sure that the padding is >> updated correctly each time a new member is added. > As long as the data description is data, writing a program to check that > a new version is compatible with the old one shouldn't be hard. If you define the structs on your own, you need to either have a data description of the padding or be very careful doing it yourself. >> Alternatively, you >> can add an allocation function that automatically pads each structure >> transparently. > Weaker than a comprehensive check, but could be good enough. > >> qmp-gen.py creates qmp-types.[ch] to do exactly the above and also >> generates the type declaration so that you don't have to duplicate the >> type marshalling code and the type declaration. Today, this is close >> to 2k LOCs so it's actually a significant amount of code code. >> >> There is also the code that takes the input (via QCFG or QMP) and >> calls an appropriate C function with a strongly typed argument. I've > Not sure I got you here. Perhaps an example could enlighten me :) void qapi_free_vnc_info(VncInfo *obj) { if (!obj) { return; } if (obj->has_host) { qemu_free(obj->host); } if (obj->has_family) { qemu_free(obj->family); } if (obj->has_service) { qemu_free(obj->service); } if (obj->has_auth) { qemu_free(obj->auth); } if (obj->has_clients) { qapi_free_vnc_client_info(obj->clients); } qapi_free_vnc_info(obj->next); qemu_free(obj); } It's pretty basic boiler plate code that could be written by hand, but why not generate it. It actually all adds up pretty quickly in terms of SLOCs. >> The mechanism I described using the visitor pattern is really the >> right solution for vmstate. The hard problems to solve for vmstate >> are: >> >> 1) How to we support old versions in a robust way. There are fancy >> things we could do once we have a proper visitor mechanism. We could >> have special marshallers for old versions, we could treat the output >> of the visitor as an in memory tree and do XSLT style translations, >> etc. >> >> 2) How do we generate the visitor for each device. I don't think it's >> practical to describe devices in JSON. It certainly simplifies the >> problem but it seems ugly to me. I think we realistically need a C >> style IDL and adopt a style of treating it as a header. > Now I'm confused. Do you mean your JSON-based DSL won't cut it for > vmstate? > > If yes, why is it wise to go down that route now? There are a few paths we could go. We can describe devices in JSON. This makes VMState introspectable with all of the nice properties of everything else. But the question is, do we describe the full device state and then use a separate mechanism to cull out the bits that can be recomputed. To we only describe the guest visible state and treat that as a separate structure? Is that embedded in the main state object or do we explicitly translate the main state object to this new type? We can pretty easily have a C-like IDL so I'm not terribly concerned about describing devices in JSON. It's about finding the right way to structure device marshalling in the long term. So yes, I think JSON is the right approach, but that doesn't mean I've figured out how to do VMState. >> Yeah, this is one of the big challenges with vmstate. There needs to >> be a clearer line between internal types and object models vs. the >> externally visible interfaces. > Not only with vmstate. If we couple QMP closely to internal interfaces, > I'm afraid we'll end up in the same unhappy place we're now with > vmstate. Yeah, it's a tough balance to strike. If you expose too much detail about internals, it's very difficult to maintain compatibility in the long term. If you have a pure external interface, it's difficult to make sure that the external interfaces are actually useful because there's no immediate feedback mechanism. Regards, Anthony Liguori >> Regards, >> >> Anthony Liguori >> >>> [...] >>> > [*] http://ccan.ozlabs.org/info/check_type.html >