qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PULL 00/69] Block patches


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PULL 00/69] Block patches
Date: Wed, 4 Mar 2015 13:03:11 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 04.03.2015 um 09:28 hat Christian Borntraeger geschrieben:
> Am 03.03.2015 um 18:33 schrieb Max Reitz:
> > On 2015-03-03 at 12:29, Christian Borntraeger wrote:
> >> Am 03.03.2015 um 15:52 schrieb Peter Maydell:
> >>> On 28 February 2015 at 03:57, Stefan Hajnoczi <address@hidden> wrote:
> >>>> On Fri, Feb 27, 2015 at 6:17 PM, Stefan Hajnoczi <address@hidden> wrote:
> >>>>> Ekaterina Tumanova (5):
> >>>>>    block: add bdrv functions for geometry and blocksize
> >>>>>    raw-posix: Factor block size detection out of raw_probe_alignment()
> >>>>>    block: Add driver methods to probe blocksizes and geometry
> >>>>>    block-backend: Add wrappers for blocksizes and geometry probing
> >>>>>    BlockConf: Call backend functions to detect geometry and blocksizes
> >>>> Max Reitz found an issue with this patch.
> >>>>
> >>>> Peter: Please squash the following trivial fix into "BlockConf: Call
> >>>> backend functions to detect geometry and blocksizes":
> >>>> https://lists.nongnu.org/archive/html/qemu-devel/2015-02/msg05512.html
> >>> I can't squash fixes into pull requests -- I can only
> >>> apply them, or not apply them. You need to respin.
> >>>
> >>>> I want to avoid spamming the list with another 60 patches.
> >>> If it's a trivial change since last time around you can just
> >>> send the cover letter to the list with a note in it that there
> >>> have only been small changes.
> >>>
> >>> -- PMM
> >>>
> >> I think you could just apply this pull request and add the fixup as 
> >> separate
> >> patch.
> >> After all it fixes a case were the command line is wrong, so should not
> >> on the critical path - I guess.
> > 
> > I agree. It's not nice to have a known break, but we're a bit behind on the 
> > pull requests already... Also, the segfault is always caused by 
> > dereferencing a null pointer, so there is no security issue.
> 
> Peter,
> 
> unless Stefan/Kevin object:
> 
> 
> can you pull the original pull request?

That makes sense to me. We'll put the fix into the next pull request
then.

Kevin



reply via email to

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