From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrsEE-0002cz-Jw for qemu-devel@nongnu.org; Mon, 30 Jan 2012 09:29:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrsE6-0002mF-65 for qemu-devel@nongnu.org; Mon, 30 Jan 2012 09:29:06 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:49100) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrsE5-0002ly-U4 for qemu-devel@nongnu.org; Mon, 30 Jan 2012 09:28:58 -0500 Received: by dajr28 with SMTP id r28so4678975daj.4 for ; Mon, 30 Jan 2012 06:28:56 -0800 (PST) Message-ID: <4F26A924.20900@codemonkey.ws> Date: Mon, 30 Jan 2012 08:28:52 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1327927984-7884-1-git-send-email-pbonzini@redhat.com> <4F269D96.8000106@codemonkey.ws> <4F26A31D.7030704@redhat.com> In-Reply-To: <4F26A31D.7030704@redhat.com> 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: Paolo Bonzini Cc: qemu-devel@nongnu.org On 01/30/2012 08:03 AM, Paolo Bonzini wrote: > 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. I think we agreed (in IRC) that we can handle this by changing qdev_resolve_path() to take an optional TYPE argument which will cause qdev_resolve_path() to only succeed if the resulting object implements TYPE. This can be used to disambiguate partial path matches such that a link property would only attempt to do partial path resolutions on objects that have BlockDriverState in their parent hierarchy. Regards, Anthony Liguori