[Qemu-devel] Re: [PATCHv6 00/16] boot order specification

[Michael S. Tsirkin]

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.

> 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.


-- 
MST