On Tue, 4 Jan 2022 15:42:22 -0600
Glenn Washburn <development@efficientek.com> wrote:
I'm generally very pro-flexibility, but I'm not sure I like this from a
user perspective. For the common case, which is detached headers in a
file, this will cause the user to do more work (create a loopback
device of the file). What's a reasonable scenario where a user would
want the detached header on a device as opposed to a file system? Am I
correct in thinking that you use such functionality?
Actually no, I only use a file for the external header, not a disk.
I have now looked at the patches again and will try to state my point of view in
more detail:
I don't think the hdr_file field as it stands in the patch set is relevant. I mean
the hdr_file field of type grub_file_t in the grub_cryptomount_args structure.
Even the grub_disk_t type may not be relevant here. You could only pass
a header file name or a disk name (as char*) through this structure. This would
reflect the essence of this structure, but further implementation the code will
not be pretty in this case.
I still suggest expanding the number of parameters for the recover_key function
and use grub_disk_t to pass the header from the user directly.