Paolo Bonzini writes:
> On 23/03/2016 10:18, Markus Armbruster wrote:
>>> In Kevin's idea there would be no ownership either way. Until then, I
>>> think my patch actually gets us closer to the ideal.
>>
>> I'm afraid it gets us closer to where we used to be six years ago :)
>>
>> Qdev drive p
On 23/03/2016 10:18, Markus Armbruster wrote:
>> In Kevin's idea there would be no ownership either way. Until then, I
>> think my patch actually gets us closer to the ideal.
>
> I'm afraid it gets us closer to where we used to be six years ago :)
>
> Qdev drive properties used to point to a D
Paolo Bonzini writes:
> On 22/03/2016 11:25, Markus Armbruster wrote:
>> Regardless of how and when we create BlockBackend, we'll want to keep
>> the clean separation between frontend and backend internally and at the
>> user interface.
>
> This means that the BlockBackend should not own the Driv
Paolo Bonzini writes:
> On 21/03/2016 18:39, Kevin Wolf wrote:
>> > When I wrote my review, I forgot that I expect x-blockdev-del to accept
>> > only backends created with blockdev-add. With that, my question is
>> > indeed moot.
>> >
>> > However, I've now tested my expectation, and it turned
On 21/03/2016 18:39, Kevin Wolf wrote:
> > When I wrote my review, I forgot that I expect x-blockdev-del to accept
> > only backends created with blockdev-add. With that, my question is
> > indeed moot.
> >
> > However, I've now tested my expectation, and it turned out to be wrong.
> > I'm incl
On 22/03/2016 11:25, Markus Armbruster wrote:
> Regardless of how and when we create BlockBackend, we'll want to keep
> the clean separation between frontend and backend internally and at the
> user interface.
This means that the BlockBackend should not own the DriveInfo. The
backend and fronte
Kevin Wolf writes:
> Am 21.03.2016 um 19:14 hat Markus Armbruster geschrieben:
>> Paolo Bonzini writes:
>>
>> > On 21/03/2016 18:30, Markus Armbruster wrote:
>> >> However, I've now tested my expectation, and it turned out to be wrong.
>> >> I'm inclined to call that a bug.
>> >
>> > --verbose,
Am 21.03.2016 um 19:14 hat Markus Armbruster geschrieben:
> Paolo Bonzini writes:
>
> > On 21/03/2016 18:30, Markus Armbruster wrote:
> >> However, I've now tested my expectation, and it turned out to be wrong.
> >> I'm inclined to call that a bug.
> >
> > --verbose, what is wrong and what was yo
Paolo Bonzini writes:
> On 21/03/2016 18:30, Markus Armbruster wrote:
>> However, I've now tested my expectation, and it turned out to be wrong.
>> I'm inclined to call that a bug.
>
> --verbose, what is wrong and what was your expectation?
x-blockdev-del should refuse to touch anything not crea
Kevin Wolf writes:
> Am 21.03.2016 um 18:30 hat Markus Armbruster geschrieben:
>> Paolo Bonzini writes:
>>
>> > On 21/03/2016 17:15, Markus Armbruster wrote:
>> >> * Explicitly with x-blockdev-del
>> >>
>> >> Fails unless no other reference exists. Where is the legacy_dinfo
>> >> released
On 21/03/2016 18:30, Markus Armbruster wrote:
> However, I've now tested my expectation, and it turned out to be wrong.
> I'm inclined to call that a bug.
--verbose, what is wrong and what was your expectation?
> > In other words, you said "This looks like DriveInfo now owns a reference
> > to
Am 21.03.2016 um 18:30 hat Markus Armbruster geschrieben:
> Paolo Bonzini writes:
>
> > On 21/03/2016 17:15, Markus Armbruster wrote:
> >> * Explicitly with x-blockdev-del
> >>
> >> Fails unless no other reference exists. Where is the legacy_dinfo
> >> released?
> >
> > Can a -drive block d
Paolo Bonzini writes:
> On 21/03/2016 17:15, Markus Armbruster wrote:
>> * Explicitly with x-blockdev-del
>>
>> Fails unless no other reference exists. Where is the legacy_dinfo
>> released?
>
> Can a -drive block device be deleted with x-blockdev-del even?!?
When I wrote my review, I forg
Paolo Bonzini writes:
> Currently, blockdev_del_drive (and before it blk_auto_del) does a blk_unref
> that will cause blk_delete to be called and the DriveInfo to be freed.
> But really, we want to free the drive info as soon as the device is
> detached, even if there are other references for wha
On 21/03/2016 17:15, Markus Armbruster wrote:
> * Explicitly with x-blockdev-del
>
> Fails unless no other reference exists. Where is the legacy_dinfo
> released?
Can a -drive block device be deleted with x-blockdev-del even?!?
In other words, you said "This looks like DriveInfo now owns
Currently, blockdev_del_drive (and before it blk_auto_del) does a blk_unref
that will cause blk_delete to be called and the DriveInfo to be freed.
But really, we want to free the drive info as soon as the device is
detached, even if there are other references for whatever reason, so
that the QemuOp
16 matches
Mail list logo
