[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