On 06/21/2016 08:20 AM, Peter Krempa wrote:
> On Mon, Jun 13, 2016 at 20:27:51 -0400, John Ferlan wrote:
>> Currently the assumption is there is one type of disk encryption - in
>> some qcow format which is old and crusty... But there's a new sheriff
>> in town known as 'luks' and we'll need to handle that shortly
>>
>> Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>
>> ---
>> src/util/virstoragefile.c | 54 ++++++++++++++++++++++++++++-------------------
>> 1 file changed, 32 insertions(+), 22 deletions(-)
>>
>> diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
>> index 6d7e5d9..5c2519c 100644
>> --- a/src/util/virstoragefile.c
>> +++ b/src/util/virstoragefile.c
>
> [...]
>
>> @@ -111,6 +111,11 @@ enum {
>> BACKING_STORE_ERROR,
>> };
>>
>> +enum fi_crypt {
>> + FI_CRYPT_NONE = 0,
>> + FI_CRYPT_QCOW
>
> This lacks the "VIR_" prefix. Also I don't really see a point in adding
> this. Currently it's used to distinguish between an encrypted QCOW and
> an unencrypted QCOW. With LUKS (as you note later in a comment) it's
> implied that they are encrypted and thus we don't need a side band to
> store the same data.
>
OK I can drop this... It would be replaced in "a" subsequent patch with
a more direct "meta->format == VIR_STORAGE_FILE_LUKS" type check in
order to allocate meta->encryption
John
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list