[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/4] luks: extract block_crypto_calculate_payload_offset()
From: |
Max Reitz |
Subject: |
Re: [PATCH v2 1/4] luks: extract block_crypto_calculate_payload_offset() |
Date: |
Wed, 15 Jan 2020 15:35:55 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 |
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 <address@hidden>
>>> ---
>>> 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
signature.asc
Description: OpenPGP digital signature