From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1JcNak-0003Ll-JI for mharc-grub-devel@gnu.org; Thu, 20 Mar 2008 12:26:10 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JcNai-0003Iv-VB for grub-devel@gnu.org; Thu, 20 Mar 2008 12:26:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JcNaf-0003BB-4h for grub-devel@gnu.org; Thu, 20 Mar 2008 12:26:08 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JcNaf-0003B2-0v for grub-devel@gnu.org; Thu, 20 Mar 2008 12:26:05 -0400 Received: from c60.cesmail.net ([216.154.195.49]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1JcNae-0008FH-JY for grub-devel@gnu.org; Thu, 20 Mar 2008 12:26:04 -0400 Received: from unknown (HELO relay.cesmail.net) ([192.168.1.81]) by c60.cesmail.net with ESMTP; 20 Mar 2008 12:26:03 -0400 Received: from [192.168.1.21] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by relay.cesmail.net (Postfix) with ESMTP id 4E23A619058 for ; Thu, 20 Mar 2008 12:26:03 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: References: <20080320040905.9tndjqzqf4so880g@webmail.spamcop.net> Content-Type: text/plain Date: Thu, 20 Mar 2008 12:26:02 -0400 Message-Id: <1206030362.31267.48.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-3.fc8) Content-Transfer-Encoding: 7bit X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: Proposal for savedefault implementation 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: Thu, 20 Mar 2008 16:26:09 -0000 On Thu, 2008-03-20 at 20:28 +0800, Bean wrote: > I think using a separate sector to store the information is not very > practical. First of all, we need to modify all of the file system > modules to support this new feature, which require non trivial work > and testing. I'm afraid you misunderstood something. Are you talking about the bootloader or about the utility for creating the sector? The bootloader should write only by the block number. No filesystem code is involved. The utility only needs to know which filesystems are safe to write to. It should also know the sector number, but I think LILO can do it somehow without any filesystem support. Even GRUB should be able to do it if it doesn't embed the core image. The worst case scenario is that we add some tracing code to our filesystem implementation (userspace only), which would record the last sector accessed for reading. This way we'll know the location of the file by reading from it. > Besides, some file system doesn't have space for extra > sector, for example, fat12/fat16. It would be annoying if this > function can't be used on such fs. What extra space are you talking about? I actually think FAT is one of the easiest filesystems to support because it has no checksums, no compression, no tail packing and no sparse files. A 512-byte long file would always occupy exactly one sector. > Perhaps we can just embed the information in core.img itself. We use > blocklist to find out the disk location and write to it. As core.img > is normally too big to fit within a filesystem cluster, we don't have > to worry about inline data. Also, we can read from the sector and > verify its content first, so that we won't overwrite other area even > if blocklist give incorrect result. I don't see much difference between using core.img and a separate file, except that using a separate file gives more flexibility. By the way, you are inconsistent here. If writing a separate file requires changes to all filesystems, how come writing to core.img doesn't require it? The only difference in my proposal is to have the blocklist (consisting of one sector) in the writable file itself, not in the bootloader. > About the format, i think storing key=value pairs is all we need. > Other information can be converted to such form. Inside grub2, we can > add a command to mark some variable as persistent, so that its value > will be written to disk automatically (or manually). OK, fine with me. -- Regards, Pavel Roskin