On Sunday 13 January 2008 21:16, Bean wrote: > > - If you want to support, for example, an ecrypted and compressed file, > > in the current implementation, each hook must try other hooks > > recursively. I believe that this should be done at grub_file_open_ex > > rather than at every hook. Is there any pitfall with this way? > > currently, at most one hook is applied to one file, recursive hook can > be messy. but we can add a priority value, this would allow the hooks > to be apply in a particular order.
In reality, the user can do both encryption+compression and compression+encryption, thus I don't think we can put priorities a priori. > > - There are some cases where the user wants to skip some decoding > > features (i.e. decryptions and decompressions). For instance, gunzip does > > not make sense for initrd, since the linux kernel performs this. But if > > the user uses other compression algorithms (e.g. LZMA), GRUB must > > decompress it before transferring control to the kernel. Or, in the case > > of Multiboot modules, an OS image might want to keep compressed modules > > as they are, but have GRUB to decrypt them, if they are encrypted. How > > does the user select which hooks should be applied (from the viewpoint of > > UI)? > > i think this can be controlled by variables, for example, we can use > filehook.gzip to control whether or not to use gzip, etc. Using variables has too much side effect. For example: grub> set something=foo,bar grub> command Since the value of the variable is applied to all files the command opens, it can lead to undesired results. Even if it is a rare case that a command wants to open multiple files differently, I don't think this is really clean. The traditional approach in GRUB is to specify options to a command. For example, --no-decompression. Then, the command hardcodes where the options are applied. As long as the combinations of such options fulfill all (realistic) use cases, this approach works quite well. But it is a nightmare to specify all possibilities, such as --no-gunzip, --no-bunzip2, and so on. So my feeling is that we need a kind of categorization in hooks. For example, gzio belongs to "compression". Once this is done, I think it would be good enough for Multiboot. For other boot protocols (such as Linux), I think loaders would require hardcoding more specific filtering (such as excluding only gzip). If hooks are named, we might be able to use the same trick as for grub_dprintf. Okuji _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
