From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4VM8-0000wk-2j for qemu-devel@nongnu.org; Fri, 16 Sep 2011 06:09:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4VM5-0005bt-P6 for qemu-devel@nongnu.org; Fri, 16 Sep 2011 06:09:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40895) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4VM5-0005bI-Bk for qemu-devel@nongnu.org; Fri, 16 Sep 2011 06:09:09 -0400 Message-ID: <4E7320F1.1020905@redhat.com> Date: Fri, 16 Sep 2011 12:12:01 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <4E70EC90.8000904@us.ibm.com> <4E7100E9.70305@web.de> <4E7103AE.5060201@codemonkey.ws> <4E711969.8030400@web.de> <4E71267A.3020808@codemonkey.ws> <4E720103.7040100@siemens.com> <4E72079D.5060103@codemonkey.ws> In-Reply-To: <4E72079D.5060103@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , Jan Kiszka , qemu-devel , Markus Armbruster , Gerd Hoffmann , "Edgar E. Iglesias" Am 15.09.2011 16:11, schrieb Anthony Liguori: > On 09/15/2011 08:43 AM, Jan Kiszka wrote: >> On 2011-09-15 00:11, Anthony Liguori wrote: >>> On 09/14/2011 04:15 PM, Jan Kiszka wrote: >>>> On 2011-09-14 21:42, Anthony Liguori wrote: >>>>>> Such names can get fairly long I'm afraid... >>>>> >>>>> A user should never even see these names. A user probably will always >>>>> interact with devices via paths. >>>> >>>> Right. >>>> >>>> But will those automatic names be used at all then? >>> >>> Yes, because QEMU is not going to know anything about path names :-) >> >> I bet that's a needless self-restriction. What prevents reusing the >> introspection services that allow path resolutions on the client side >> also QEMU internally? It would enable us to skip any traps and pitfalls >> associated with unique device name construction. From a higher >> perspective, they are completely redundant. > > I actually agree :-) > > We should probably pick a path format and implement in QMP. I think that > discussion is orthogonal though. > >>> Path names should be a concept that exists entirely in the client. That >>> may be HMP or that may be a command line tool (like the proposed qemu >>> script). >>> >>> The only management interface exposed to the client is: >>> >>> create_object(type, name) >>> value = get_object_property(name, property_name) >>> void set_object_property(name, property_name, value) >>> props = list_object_properties(name) >>> names = list_objects() >>> >>> So names are very important from a QMP perspective, but not something >>> users every really see. >> >> I don't get the added value of something that looks almost like a path >> but is still not as readable at it (e.g. when debugging the communication). > > It's two separate namespaces. The name namespace is controlled by the user and > we have to bend over backwards to avoid clashing with it. > > The path namespace is controller by QEMU (more or less). > > The name namespace also maps 1-1 to devices which means names can be used to > represent devices. They absolutely never change as long as the device never > changes. > > Paths maps N-1 to devices. Paths may change but names never change. I don't > think there can ever be a fixed canonical path. > > An example is a NIC with nvram that stores a mac address. In QOM, the guest > could change the mac address, then a user could hot unplug the device, and then > hot plug the device into a different PCI slot. The path is now different but > the device name has not change. Maybe then the device name shouldn't default to something that looks like a path but rather something like "#foo-1" where "foo" is a device name and "1" a counter for devices of the same type (I'm reusing Jan's # notation in order to avoid clashes with user specified names, but that's a detail). I guess a name like that would actually be relatively convenient to use from a user interface like HMP. Kevin