From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1JE9pq-0006mW-Ct for mharc-grub-devel@gnu.org; Sun, 13 Jan 2008 15:53:38 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JE9po-0006li-Mm for grub-devel@gnu.org; Sun, 13 Jan 2008 15:53:36 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JE9pn-0006j1-6E for grub-devel@gnu.org; Sun, 13 Jan 2008 15:53:36 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JE9pn-0006im-33 for grub-devel@gnu.org; Sun, 13 Jan 2008 15:53:35 -0500 Received: from ns39764.ovh.net ([91.121.25.85] helo=nexedi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JE9pm-0000VK-JH for grub-devel@gnu.org; Sun, 13 Jan 2008 15:53:34 -0500 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id AA8FD3EB24 for ; Sun, 13 Jan 2008 21:58:58 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sun, 13 Jan 2008 21:53:32 +0100 User-Agent: KMail/1.9.4 References: <200801132051.53894.okuji@enbug.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801132153.32895.okuji@enbug.org> X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Subject: Re: Transparent decompression with file system filter X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2008 20:53:37 -0000 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