ср, 5 янв. 2022 г. в 02:30, Dmitry <reagen...@gmail.com>: > > > ср, 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 >> > So, please ignore these statements. Looks like it's not valid.
> 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
