Re: Transparent decompression with file system filter

["Yoshinori K. Okuji" <okuji@enbug.org>]

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