From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LlHgw-0001sN-OF for mharc-grub-devel@gnu.org; Sun, 22 Mar 2009 03:01:54 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LlHgu-0001sI-SS for grub-devel@gnu.org; Sun, 22 Mar 2009 03:01:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LlHgt-0001s6-1L for grub-devel@gnu.org; Sun, 22 Mar 2009 03:01:51 -0400 Received: from [199.232.76.173] (port=54387 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LlHgs-0001s3-Tt for grub-devel@gnu.org; Sun, 22 Mar 2009 03:01:50 -0400 Received: from mx20.gnu.org ([199.232.41.8]:40001) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LlHgs-00055s-2A for grub-devel@gnu.org; Sun, 22 Mar 2009 03:01:50 -0400 Received: from mail.nexedi.com ([91.121.25.85] helo=nexedi.com) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LlHgq-0004mm-P5 for grub-devel@gnu.org; Sun, 22 Mar 2009 03:01:49 -0400 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id 2B84A3D9EF for ; Sun, 22 Mar 2009 08:01:42 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sun, 22 Mar 2009 16:01:35 +0900 User-Agent: KMail/1.9.10 References: <49A50DA2.20604@netsyncro.com> <200903150610.40823.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: <200903221601.36503.okuji@enbug.org> X-detected-kernel: by mx20.gnu.org: Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09) 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, 22 Mar 2009 07:01:53 -0000 On Sunday 15 March 2009 14:52:05 Bean wrote: > On Sun, Mar 15, 2009 at 5:10 AM, Yoshinori K. Okuji wrote: > > On Friday 13 March 2009 21:23:19 phcoder wrote: > >> Look at load_env/save_env commands and grub-editenv util > > > > Thanks. Now I really regret that I didn't find those additions earlier. > > > > I do not like this implementation for the following reasons: > > > > - The saved file is not plain text, unlike GRUB Legacy. This is a bad > > choice. Please let me know the reason why it must be binary, if any. > > Hi, > > As the command need to write to disk using blocklist information, > which is not always correct (such as tail packing, sparse block), I > use a magic header for verification. The length field is used to > indicate the length of the block. because the command can't expand > file, otherwise it would need to update fs information, which is too > much for grub. I have read your code deeply, and have found the following: - in reality, you don't deal with tail packing, but just refuse it, because of this check in the hook function: if ((offset != 0) || (length != GRUB_DISK_SECTOR_SIZE)) return; - grub-editenv and save_env always write the magic at the beginning of a file, thus the magic does not make sense (besides an extremely conservative sanity check). I would say that this is a regression from GRUB Legacy, which takes care of partial sector allocations gracefully. So, assuming that every filesystem driver calls a read hook correctly, we should change it for: - eliminating the magic header (although it could be kept for a safety guard for accidental writes) - refusing to write, only if any sparse blocks are in use (as GRUB may not allocate new sectors physically) - dealing with partial sectors - possibly due to tail packing - with some complicated code I will work towards this direction. I will first fix up the sector handling and change the format to plain text. Naming changes are quite trivial, so they can be done later. Regards, Okuji > > > - The command names are ugly. Why didn't anybody follow Pavel's advise > > using "env"? > > > > - The utility name is also ugly. I like Pavel's suggestion "grub-env". > > > > If nobody stops me, I will rewrite it in one week, without caring about > > backward compatibility. > > I have no objection for the rename, although there should be two env > commands, one to load and one to save.