From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4fZc-0004GN-Mp for qemu-devel@nongnu.org; Fri, 16 Sep 2011 17:03:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4fZb-0006qW-53 for qemu-devel@nongnu.org; Fri, 16 Sep 2011 17:03:48 -0400 Received: from mail-gw0-f53.google.com ([74.125.83.53]:37821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4fZb-0006qM-0F for qemu-devel@nongnu.org; Fri, 16 Sep 2011 17:03:47 -0400 Received: by gwj20 with SMTP id 20so4228248gwj.12 for ; Fri, 16 Sep 2011 14:03:46 -0700 (PDT) Message-ID: <4E73B9AE.4090902@codemonkey.ws> Date: Fri, 16 Sep 2011 16:03:42 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E723B1B.5070805@codemonkey.ws> <20110915202907.GG11524@redhat.com> <20110916163326.GA11160@redhat.com> <4E73909B.3050900@codemonkey.ws> <20110916182246.GD11160@redhat.com> <4E73987A.1090803@codemonkey.ws> <20110916191352.GE11160@redhat.com> <4E73A3AF.3030507@codemonkey.ws> <20110916204808.GF11160@redhat.com> In-Reply-To: <20110916204808.GF11160@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Gleb Natapov Cc: Peter Maydell , Jan Kiszka , qemu-devel , Markus Armbruster , Gerd Hoffmann , Paolo Bonzini , "Edgar E. Iglesias" On 09/16/2011 03:48 PM, Gleb Natapov wrote: > On Fri, Sep 16, 2011 at 02:29:51PM -0500, Anthony Liguori wrote: >> On 09/16/2011 02:13 PM, Gleb Natapov wrote: >>> On Fri, Sep 16, 2011 at 01:42:02PM -0500, Anthony Liguori wrote: >>>> On 09/16/2011 01:22 PM, Gleb Natapov wrote: >>>>> Then we are arguing about minor detail. But according to you this minor >>>>> detail will prevent us from walking device tree up to the root, so it is >>>>> not so minor for me. >>>> >>>> There is no root. It's not a tree. The composition tree (which >>> There is "virtual root". System bus in qdev speak. You can create one >>> explicitly like qdev did or you can say that if a device has no parent >>> it is on a system bus. >> >> Graphs don't have roots. >> > Lets not pretend that this device graph is absolutely arbitrary. > >>>> we've been talking about using for canonical pathnames) has nothing >>>> to do with the buses. >>>> >>> >>> I do not care about canonical pathnames you are talking about too >>> much. The reason is that they are useless outside of QEMU. The problem >>> we need to solve is to name a device in such a way that it can be found >>> without knowing any QEMU implementation details. This is not for internal >>> QEMU use (for that you can use canonical pathnames you are talking about), >>> but for communicating device location outside of QEMU. Currently we pass >>> OF device paths to firmware and this is ABI QEMU expose to a guest, so >>> QOM needs to preserve it. What I asked is how it can be done with QOM and >>> you are saying that it can't be done and this is not a very good answer. >> >> No, it's very easy. Something just has to decide where to start the >> transversal, and then walk the graph starting at that node until >> they find the node. They need to map each node to whatever the OF >> representation is that makes sense. >> > That is obvious thing to do, but you said not all devices have a link to > a parent node which will make such traversal impossible. No, it's really as simple as this: bool build_of_path(Device *node, Device *target, char *path) { if (IS_PCI_BUS(node)) { for (int i = 0; i < 32; i++) { PciBus *bus = PCI_BUS(node); if (build_of_path(bus->slot[i], target, path)) { strappend(path, "/pci@%d", i); return true; } } } else if (IS_ISA_BUS(node)) { IsaBus *bus = ISA_BUS(node); for (int i = 0; i < bus->nb_slots; i++) { if (build_of_path(bus->slots[i], target, path)) { strappend(path, "/isa@" TARGET_FMT_plx, bus->slots[i]->mem.base); return true; } } } else if (node == target) { return true; } return false; } This uses centralized logic which I think is the right thing to do. You could also have an OpenFirmwareCompatBus interface which implemented this logic within each bus and then a bus could choose to implement this interface. I think centralized is better though. > Another thing > is that graph needs to contain enough information (nodes) to create > correct path. If a bus is omitted resulting path will not be accurate. It's really not that different from what we have today except that you can interact better with the devices in C. Whereas there is no way today to read the "iobase" property of the IsaSerial device, there would be an isa_serial_get_iobase() in QOM that the property would be automatically implemented in terms of. >> A tree is just a degenerate graph so going from QOM to OF is easy. >> It just requires looking at a subset. >> >>> ABI requires OF path to be built not for all QEMU devices, but only for >>> those that support bootindex property, so this may make our task more >>> simple, although I think the correct solution should be generic. >> >> To be fair, it's not an ABI that is supported. We only need to >> support a single BIOS version that we provide. > Yes, but how is this help us here? We will still have to provide some > device identification, that is independent from QEMU internals, to > a firmware. We chose to use OF because it is established standard and > using something different will be NIH. Seabios is not the only QEMU's > firmware and Seabios is used not only with QEMU (and coreboot is/will be > able to pass bootorder to Seabios the same way QEMU does). So inventing > QEMU specific format, that will have to contain all the same information > about device as OF path anyway, is just spreading NIH around. No one is suggesting getting rid of OF paths. You're confusing constructing paths with device naming. They are not the same thing. Regards, Anthony Liguori > >> >> But that's just splitting hairs. You can still generate these paths. >> >> Regards, >> >> Anthony Liguori > > -- > Gleb. >