From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1JE8sG-0002Cc-91 for mharc-grub-devel@gnu.org; Sun, 13 Jan 2008 14:52:04 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JE8sC-00028m-FV for grub-devel@gnu.org; Sun, 13 Jan 2008 14:52:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JE8sA-000271-VX for grub-devel@gnu.org; Sun, 13 Jan 2008 14:52:00 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JE8sA-00026s-N7 for grub-devel@gnu.org; Sun, 13 Jan 2008 14:51:58 -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 1JE8sA-0007Sk-F1 for grub-devel@gnu.org; Sun, 13 Jan 2008 14:51:58 -0500 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id 312EC3EB24 for ; Sun, 13 Jan 2008 20:57:21 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sun, 13 Jan 2008 20:51:53 +0100 User-Agent: KMail/1.9.4 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801132051.53894.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 19:52:01 -0000 On Sunday 13 January 2008 08:38, Bean wrote: > Hi, > > any suggestion about this patch ? i would like to commit it soon. I am sorry that I forgot to reply. I would like to know how you intend to approach the following issues: - 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? - 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)? Because your aim is quite broad (which is a good thing), I think we need to consider possible use cases carefully, to make sure that the API is good enough. Okuji