From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.33) id 1CEROE-00073A-P5 for mharc-grub-devel@gnu.org; Mon, 04 Oct 2004 07:52:26 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CEROC-00072o-Vb for grub-devel@gnu.org; Mon, 04 Oct 2004 07:52:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CEROC-00072W-7g for grub-devel@gnu.org; Mon, 04 Oct 2004 07:52:24 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CEROC-00072M-2G for grub-devel@gnu.org; Mon, 04 Oct 2004 07:52:24 -0400 Received: from [145.74.66.11] (helo=mail-cn.han.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CERHT-0008GD-Qs for grub-devel@gnu.org; Mon, 04 Oct 2004 07:45:28 -0400 Received: from localhost (charlie.han.nl [145.74.66.9]) by mail-cn.han.nl (Postfix) with ESMTP id 53E8282CC for ; Mon, 4 Oct 2004 13:45:27 +0200 (CEST) Received: from mail-cn.han.nl ([145.74.66.11]) by localhost (charlie.han.nl [145.74.66.9]) (amavisd-new, port 10024) with ESMTP id 18618-01 for ; Mon, 4 Oct 2004 13:45:24 +0200 (CEST) Received: from mail1.han.nl (mail1.han.nl [145.74.103.11]) by mail-cn.han.nl (Postfix) with ESMTP id C5D748F5D for ; Mon, 4 Oct 2004 13:45:24 +0200 (CEST) Received: from marco.marco-g.com (mgerards.xs4all.nl [82.92.27.129]) by mail1.han.nl (Postfix) with ESMTP id 6D719C046 for ; Mon, 4 Oct 2004 13:45:24 +0200 (CEST) Mail-Copies-To: metgerards@student.han.nl To: The development of GRUB 2 References: From: Marco Gerards Date: Mon, 04 Oct 2004 11:45:37 +0000 In-Reply-To: (Hollis Blanchard's message of "Sun, 3 Oct 2004 22:40:17 -0500 (CDT)") Message-ID: <87sm8uso4e.fsf@marco.marco-g.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new@vscan-cn.han.nl Subject: Re: [RFC] post-processing tool 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: Mon, 04 Oct 2004 11:52:25 -0000 Hollis Blanchard writes: > Linux uses a post-processing tool called addnote to add the NOTE segment > to a normal ELF file. I have written my own version of that, which I'm > calling "appendnote" to avoid confusion. If it goes into GRUB, it probably > belongs in a util/powerpc/ieee1275 directory. This sounds sane to me. > I don't believe there exists a grub-setup for PPC, but this could warrant > it. One could run grub-setup on the target machine, which could be a shell > script that does the following: > > - if the system is Old World Mac, install stage1 with a block list for > grubof > - if CHRP, run appendnote on grubof > - if CHRP or New World: > - find the OF device path to grubof (like ybin or SUSE's "lilo" script) > - use nvsetenv to point firmware to grubof Doesn't ybin mount the boot partition and copy yaboot there? I think we have to do the same. > In that model, appendnote would be a tool compiled and installed on the > target. The alternative is to create grubof and grubof.chrp at compile > time, install both on the target, and let grub-setup point OF at one or > the other. Both are fine for me. But the advantage of having grubof and grubof.chrp is that distributions just need one package for multiple platforms. > Any comments? How do I add this tool to the Makefiles? Add it to sbin_UTILITIES. BTW, I think grubof does not belong there, but there is not a better place yet. When module loading is implemented on the PPC, I will work on powerpc-ieee1275.rmk to make it a bit more like the PC version. Perhaps it would be nice if this utility checks if the ELF is a powerpc ELF. > struct chrp_note { > Elf32_Nhdr header; > unsigned char name[8]; > uint32_t real_mode; > uint32_t real_base; > uint32_t real_size; > uint32_t virt_base; > uint32_t virt_size; > uint32_t load_base; > }; Can you please revise this so the GCS is followed. In the GCS tabs are not used, but instead of that two spaces. Also braces are on their own lines. So this code will look like: struct chrp_note { Elf32_Nhdr header; unsigned char name[8]; uint32_t real_mode; uint32_t real_base; uint32_t real_size; uint32_t virt_base; uint32_t virt_size; uint32_t load_base; }; > off_t segtable_size(void *file) Please put the return type on a separate line. Add a space after the function name. > return elf_header->e_phentsize * elf_header->e_phnum; In case of a pointer, don't add a space after the star. > if (argc < 3) { > fprintf (stderr, "Usage: %s \n", argv[0]); > return 1; > } Is it possible to use a parser? I prefer argp, but we need to agree what to use for utilities? This is also in the GCS to keep the GNU utilities consistent. For example the help output should be consistent with other utilities and --help should be accepted. When using such parser we get all that for free. :) I could do that if you want, I am used to argp and can implement such thing in a few minutes. Can you please modify the program so it is GCS compliant? For me it is important to have a consistent coding style in GRUB. It is not a problem for me to change all this, but it is a lot of work for me so I prefer not to do this for every patch. :) Thanks, Marco