From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39992 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PMmnX-0007R4-7m for qemu-devel@nongnu.org; Sun, 28 Nov 2010 14:20:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PMmnV-0005ej-TD for qemu-devel@nongnu.org; Sun, 28 Nov 2010 14:20:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:24165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PMmnV-0005ec-LT for qemu-devel@nongnu.org; Sun, 28 Nov 2010 14:20:29 -0500 Date: Sun, 28 Nov 2010 21:20:23 +0200 From: Gleb Natapov Message-ID: <20101128192023.GH14385@redhat.com> References: <1290012243-6087-1-git-send-email-gleb@redhat.com> <20101123153141.GD25606@redhat.com> <4CEBE7F4.9080200@linux.vnet.ibm.com> <4CF1706A.3000507@redhat.com> <20101128075404.GF6897@redhat.com> <20101128131352.GA12874@redhat.com> <20101128131900.GC2187@redhat.com> <20101128172320.GG12874@redhat.com> <20101128185438.GF14385@redhat.com> <20101128190948.GA17063@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101128190948.GA17063@redhat.com> Subject: [Qemu-devel] Re: [PATCHv6 00/16] boot order specification List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Anthony Liguori , kvm@vger.kernel.org, armbru@redhat.com, qemu-devel@nongnu.org, blauwirbel@gmail.com, Anthony Liguori , alex.williamson@redhat.com, kevin@koconnor.net, Avi Kivity On Sun, Nov 28, 2010 at 09:09:48PM +0200, Michael S. Tsirkin wrote: > On Sun, Nov 28, 2010 at 08:54:38PM +0200, Gleb Natapov wrote: > > On Sun, Nov 28, 2010 at 07:23:20PM +0200, Michael S. Tsirkin wrote: > > > On Sun, Nov 28, 2010 at 03:19:00PM +0200, Gleb Natapov wrote: > > > > On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote: > > > > > On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote: > > > > > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote: > > > > > > > On 11/23/2010 06:12 PM, Anthony Liguori wrote: > > > > > > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote: > > > > > > > >>Anthony, Blue > > > > > > > >> > > > > > > > >>No comments on this patch series for almost a week. Can it be applied? > > > > > > > > > > > > > > > >Does that mean everyone's happy or have folks not gotten around to > > > > > > > >review it? > > > > > > > > > > > > > > > >IOW, last call if you have objections :-) > > > > > > > > > > > > > > > > > > > > > > I haven't reviewed this - I trust the author and maintainers to get > > > > > > > it right. > > > > > > > > > > > > > > But I notice the there is no documentation - surely some is needed? > > > > > > > > > > > > > > > > > > > The patch creates Openfirmware device path from qdev > > > > > > hierarchy. Each element of a device path depends on type of a bus > > > > > > the device resides on. You can find various bus bindings here: > > > > > > http://playground.sun.com/1275/bindings/ and main spec is here > > > > > > > > > > sun.com links have a tendency to disappear nowdays :) > > > > > Is this the official location? Aren't bindings part of some standard? > > > > I think this is official location. > > > > > > > > > > It also worries me that PCI Express bindings are in a 'proposal' form > > > > > from August 2004. The PCI bindings are from 1994. They are likely to miss > > > > > some recent technology advancements :) > > > > > > > > > > > > > > > Further, while this last document which is only 28 page in length, is > > > > > not readable by itself: one must first digest the openfirmware spec. > > > > > However ... > > > > > > > > > > > http://forthworks.com/standards/of1275.pdf. > > > > > > > > > > That's 266 pages of a specification. I am guessing that most of it is > > > > > irrelevant for the task in question? Can we have a small text document > > > > > including just the path format, please? > > > > > > > > > So basically you are complaining that reading specs is difficult. It is. That's > > > > life. > > > > > > Well, the specific format used is undocumented. Patch borrowed bits from > > > various specs, but it's undocumented which bits, and from which specs. > > > > > See above for documentation. Download everything. Read. > > > > > I do realize you had to go over all of these specs and do the difficult work > > > to come up with the format, but please write documentation > > > for the rest of us. > > > > > Pleas read spec. You can even find that I interpreted spec incorrectly > > and point where the bug is. > > Seems a waste of time. As long as qemu and BIOS agree, it does > not matter what does the spec say. > So what. I don't get this "summarize spec for me here" request. > > That is the reason spec exists. I do not > > ask you to provide me with documentation for each and every thing you do > > in pci layer although it will be much simpler to read your executive > > summery then go and read complicated spec. The same hold true for any > > other piece of code that implement spec. > > > > -- > > Gleb. > > PCI is a hardware spec that guest drivers rely on for functionality. If > we implement it incorrectly, guests break. We also implement a large > part of the spec, quite unlike this case. The spec is also > organazed in the way that maps to our code. So if you > have msix.c, you look up msix in table of content and > you got it. And, we are adding pointers to spec chapters as we go on. > > With next patch to pci summarize pci spec for me please. It is to big and complex for me to understand in 3 minutes I have to look at it. -- Gleb.