On 15.01.20 14:40, Stefan Hajnoczi wrote:
> On Tue, Jan 14, 2020 at 04:25:44PM +0100, Max Reitz wrote:
>> On 09.01.20 12:10, Stefan Hajnoczi wrote:
>>> The qcow2 .bdrv_measure() code calculates the crypto payload offset.
>>> This logic really belongs in block/crypto.c where it can be reused by
>>> other image formats.
>>>
>>> The "luks" block driver will need this same logic in order to implement
>>> .bdrv_measure(), so extract the block_crypto_calculate_payload_offset()
>>> function now.
>>>
>>> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
>>> ---
>>>  block/crypto.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  block/crypto.h |  5 ++++
>>>  block/qcow2.c  | 59 ++++------------------------------------------
>>>  3 files changed, 73 insertions(+), 55 deletions(-)
>>>
>>> diff --git a/block/crypto.c b/block/crypto.c
>>> index 24823835c1..ed32202fa2 100644
>>> --- a/block/crypto.c
>>> +++ b/block/crypto.c
>>> @@ -185,6 +185,70 @@ block_crypto_create_opts_init(QDict *opts, Error **errp)
>>
>> [...]
>>
>>> +/* Determine the number of bytes for the crypto header */
>>> +bool block_crypto_calculate_payload_offset(QemuOpts *opts,
>>> +                                           const char *optprefix,
>>> +                                           size_t *len,
>>> +                                           Error **errp)
>>> +{
>>> +    QDict *cryptoopts_qdict;
>>> +    QCryptoBlockCreateOptions *cryptoopts;
>>> +    QCryptoBlock *crypto;
>>> +
>>> +    /* Extract options into a qdict */
>>> +    if (optprefix) {
>>> +        QDict *opts_qdict = qemu_opts_to_qdict(opts, NULL);
>>> +
>>> +        qdict_extract_subqdict(opts_qdict, &cryptoopts_qdict, optprefix);
>>> +        qobject_unref(opts_qdict);
>>> +    } else {
>>> +        cryptoopts_qdict = qemu_opts_to_qdict(opts, NULL);
>>> +    }
>>> +
>>> +    /* Build QCryptoBlockCreateOptions object from qdict */
>>> +    qdict_put_str(cryptoopts_qdict, "format", "luks");
>>
>> Should this be a parameter?
> 
> Maybe one day, but there are no users who need it yet.

Sure, but would it hurt? O:-)

I’m just asking because this file doesn’t implement luks crypto, so it
seems a bit strange to reference it here.  Actually, now that I think
about it...  This file only implements the luks block driver.  Is this
even the right place for the common
block_crypto_calculate_payload_offset() function?  Would it make more
sense in crypto/block.c or crypto/block-luks.c?

Max