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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
