[dm-crypt] comment on API for saving and restoring luks header.

[dm-crypt] comment on API for saving and restoring luks header.

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

/**
 * Backup header and keyslots to file
 *
 * @param cd crypt device handle
 * @param requested_type type of header to backup
 * @param backup_file file to backup header to
 *
 * @return @e 0 on success or negative errno value otherwise.
 *
 */

The above is a comments on options for "crypt_header_backup" and
"crypt_header_restore".

The comment does not have "use @e NULL for all known" explanation for the
second argument.

Should i assume this is an oversight and use "NULL" for the second argument?

[-- Attachment #2: Type: text/html, Size: 609 bytes --]

Re: [dm-crypt] comment on API for saving and restoring luks header.

[Milan Broz]

On 04/18/2012 11:19 PM, .. ink .. wrote:
> 
> /**
>  * Backup header and keyslots to file
>  *
>  * @param cd crypt device handle
>  * @param requested_type type of header to backup
>  * @param backup_file file to backup header to
>  *
>  * @return @e 0 on success or negative errno value otherwise.
>  *
>  */
> 
> The above is a comments on options for "crypt_header_backup" and "crypt_header_restore".
> 
> The comment does not have "use @e NULL for all known" explanation for the second argument.
> 
> Should i assume this is an oversight and use "NULL" for the second argument?

The only format currently supporting this is LUKS anyway, but NULL is supported.

Better now?
http://wiki.cryptsetup.googlecode.com/git/API/libcryptsetup_8h.html#a0bba6108652c028e6e72e933a3a5de05

Milan

Re: [dm-crypt] comment on API for saving and restoring luks header.

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

> The only format currently supporting this is LUKS anyway, but NULL is
> supported.
>
> Better now?
>
> http://wiki.cryptsetup.googlecode.com/git/API/libcryptsetup_8h.html#a0bba6108652c028e6e72e933a3a5de05
>
> Milan
>

Much better :-) its always better to confirm things when possible.

luks seem to be of type "LUKS1". I assume "LUKS2" will show up at some
point in the future and specifying "LUKS1" on "LUKS2" volumes will fail.
"NULL" seem to be "future" proof option and i wanted to use it but i though
i should confirm since it wasnt mentioned.

[-- Attachment #2: Type: text/html, Size: 1004 bytes --]