On Thu, 2020-03-12 at 06:56 -0500, Eric Blake wrote:
> On 3/8/20 10:18 AM, Maxim Levitsky wrote:
> > Hi!
> > Here is the updated series of my patches, incorporating all the feedback I
> > received.
> >
> > Patches are strictly divided by topic to 3 groups, and each group depends
> > on former groups.
> >
> > * Patches 1,2 implement qcrypto generic amend interface, including
> > definition
> > of structs used in crypto.json and implement this in luks crypto driver
> > Nothing is exposed to the user at this stage
> >
> > * Patches 3-9 use the code from patches 1,2 to implement qemu-img amend
> > based encryption slot management
> > for luks and for qcow2, and add a bunch of iotests to cover that.
> >
> > * Patches 10-13 add x-blockdev-amend (I'll drop the -x prefix if you like),
> > and wire it
> > to luks and qcow2 driver to implement qmp based encryption slot
> > management also using
> > the code from patches 1,2, and also add a bunch of iotests to cover this.
> > tests/qemu-iotests/284.out | 6 +-
> > tests/qemu-iotests/300 | 207 ++++++++++++++++
>
> Any reason why you skipped straight to test 300, rather than using an
> available slot like 290? (Admittedly, our process for reserving slots
> is not very high-tech: manually scan the list for what other patches out
> there have claimed a slot, and be prepared to renumber when rebasing)
The only reason I used these slots is that I know sadly that I'll have to
resend and
rebase this patchset for a while, and every time a test with the number I use
is added,
this causes relatively hard to fix conflict (or at least I don't know how to
fix these conflicts effectively)
Thus I used safe numbers, but at the rate this task progresses I won't be
surprised that when this is merged,
these will be test numbers to use...
TL;DR - these are placeholders, and once the patch set is blesssed for merging
upstream I'll update this next
available numbers.
Best regards,
Maxim Levitsky
