From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrrpI-0007SZ-J8 for qemu-devel@nongnu.org; Mon, 30 Jan 2012 09:03:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrrpE-0006lv-6z for qemu-devel@nongnu.org; Mon, 30 Jan 2012 09:03:20 -0500 Received: from mx1.redhat.com ([209.132.183.28]:19590) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrrpE-0006ll-0O for qemu-devel@nongnu.org; Mon, 30 Jan 2012 09:03:16 -0500 Message-ID: <4F26A31D.7030704@redhat.com> Date: Mon, 30 Jan 2012 15:03:09 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1327927984-7884-1-git-send-email-pbonzini@redhat.com> <4F269D96.8000106@codemonkey.ws> In-Reply-To: <4F269D96.8000106@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH] generalize QOM path resolution List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On 01/30/2012 02:39 PM, Anthony Liguori wrote: > On 01/30/2012 06:53 AM, Paolo Bonzini wrote: >> Right now, resolving a string to an object is not generic to QOM, >> but rather it is entirely embedded in qdev (the Device class). >> This embryo patch generalizes the concept adding a resolve_path >> class method, and get_canonical_path instance method, to Object. > > https://github.com/aliguori/qemu/commit/c354035aa4d2e30eb4d3864c5a7d8e9ef23a7deb > > This is in series 3/4 which I'm going to try to clean up enough to post > today. Yeah, there's many good things in there and we happen to disagree on this one. :) >> Link properties use the type to direct sets to the right resolve_path >> method, while the qom-{get,set,list} commands get a class argument. >> >> This is needed to have different namespaces for devices, host drives, >> host chardevs, etc. and to make block/chardev/etc. properties be simply >> links (after QOMification). > > I'm not sure I understand... There should be one global namespace and > only one global namespace. > > We can maintain compatibility by giving each legacy command option it's > own directory within the tree (just like we stick -device creations into > /peripherial, -drive would have a /drive sub directory). I think that you're giving too much weight to the "legacy" aspect. We should try to design things so that (while keeping good taste overall) the legacy parts can be minimized asap and instead the QOM view of the world starts surfacing into the upper layers---including the command-line. Striving for perfection means that we'll be stuck forever with large legacy pieces and no dogfooding for the cool bits. One of the next things I want to do is to remove the legacy properties when the normal ones do exactly the same. For property types that are using get_generic/set_generic we can basically change the upper layers to use get/set directly instead of parse/print. Most of these cases, in turn, are going to become link properties to block devices or character devices. Here are two things I absolutely would like to avoid: 1) having the legacy aspect disappear for now, only to reappear after block or character devices are converted to QOM; 2) having to introduce legacy properties whose QOM counterpart is a link. Once we have QOMified enough that a property can be a link, you should be able to drop its legacy counterpart. I see your point about having a single global namespace, but shoehorning entirely different branches of the tree into the same namespace introduces gratuitous incompatibilities between the qdev and the QOM views of the world. And these are bad, because they limit the amount of QOM dogfooding that we can do inside QEMU itself. You are not going to have anyway a link. That makes it fine to resolve a link and a link according to different rules. > We provide 100% ABI compatibility with QOM. The rules to achieve that are: > > 1) Once a type name is used, it never has a different semantic meaning. > > 2) Once a property is added to a type, it never has different semantic > meaning. It's QOM property type may change, provided that the types are > Visitor-compatible. > > 3) Types can be removed and properties can be removed. That sounds good. Paolo