qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gleb Natapov
Subject: [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
Date: Sun, 28 Nov 2010 21:20:23 +0200

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]