Hi Thomas, Quick answer; apologies if I miss some subtleties.
Thomas Albers 写道：
My suggestion would be to add a "extra-options" field to<mapped-device> structure. This field would be appended to the commandline arguments to the cryptsetup call. One could also add a "keyfile" parameter but this would be too specific to the luks device mapper
Well, so is a field to add crypsetup-specific command-line arguments.
Abstracting this into meaningful field names like key-file is better from a readability point of view and allows implementation details like ‘we simply invoke cryptsetup’ to remain properly hidden from view.
Because naturally, one day cryptsetup will be rewritten in Guile.
For example, not everyone would like to store the keyfile inside thestore.
I think it could still be a plain string passed straight to cryptsetup, with the user responsible for its existence.
Also, is it possible to modify existing code for such small changes, without needing to rewrite complete functions? Many of the functionsused are not exposed by the modules and one needs to rewrite the function one wants to use and also its dependencies.
You can force access to unexported symbols using (@@ (name of module) symbol). It's as recommended as it sounds. Nor can you rewrite parts of compiled procedures AFAIK.
My last question would be: Why is the file called initrd, when inreality a initramfs scheme is used?
Saves space :-)Conceptually, they are the same thing. Nobody who knows what ‘initrd’ means will read the word in 2021 and think the distribution literally only supports pre-2005 ramdisks.
It also keeps us consistent with GRUB, which uses ‘initrd’. Kind regards, T G-R
signature.asc
Description: PGP signature
