ср, 5 янв. 2022 г. в 01:57, Dmitry <reagen...@gmail.com>: > > > ср, 5 янв. 2022 г. в 01:07, Glenn Washburn <developm...@efficientek.com>: > >> On Tue, 4 Jan 2022 15:42:22 -0600 >> Glenn Washburn <developm...@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. >
Although in general I'm quite satisfied with the current patch set. It suits my requirements. Maybe disk may be really useless and I overdid it.. It will only remain to add the master key parameter in the future.
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
