[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Transparent decompression with file system filter
From: |
Yoshinori K. Okuji |
Subject: |
Re: Transparent decompression with file system filter |
Date: |
Sun, 13 Jan 2008 21:53:32 +0100 |
User-agent: |
KMail/1.9.4 |
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
- Re: Transparent decompression with file system filter, (continued)
Re: Transparent decompression with file system filter, Vesa Jääskeläinen, 2008/01/03
- Re: Transparent decompression with file system filter, Yoshinori K. Okuji, 2008/01/04
- Re: Transparent decompression with file system filter, Bean, 2008/01/05
- Re: Transparent decompression with file system filter, Yoshinori K. Okuji, 2008/01/05
- Re: Transparent decompression with file system filter, Bean, 2008/01/05
- Re: Transparent decompression with file system filter, Bean, 2008/01/13
- Re: Transparent decompression with file system filter, Yoshinori K. Okuji, 2008/01/13
- Re: Transparent decompression with file system filter, Bean, 2008/01/13
- Re: Transparent decompression with file system filter,
Yoshinori K. Okuji <=