From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1DM7nd-00021b-Ob for mharc-grub-devel@gnu.org; Thu, 14 Apr 2005 13:06:41 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DM7nY-0001zp-4L for grub-devel@gnu.org; Thu, 14 Apr 2005 13:06:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DM7nS-0001xZ-Oa for grub-devel@gnu.org; Thu, 14 Apr 2005 13:06:31 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DM7nS-0001x1-4t for grub-devel@gnu.org; Thu, 14 Apr 2005 13:06:30 -0400 Received: from [145.74.66.11] (helo=mail-cn.han.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DM7nJ-0005xK-GV for grub-devel@gnu.org; Thu, 14 Apr 2005 13:06:21 -0400 Received: from vscan-cn.han.nl (venus.han.nl [145.74.65.6]) by mail-cn.han.nl (Postfix) with ESMTP id 57FA389D5 for ; Thu, 14 Apr 2005 19:05:41 +0200 (CEST) Received: from mail-cn.han.nl ([145.74.66.11]) by vscan-cn.han.nl (venus.han.nl [145.74.65.6]) (amavisd-new, port 10024) with ESMTP id 18110-07 for ; Thu, 14 Apr 2005 19:05:39 +0200 (CEST) Received: from mail1.han.nl (mail1.han.nl [145.74.103.11]) by mail-cn.han.nl (Postfix) with ESMTP id 5F3C0879B for ; Thu, 14 Apr 2005 19:05:39 +0200 (CEST) Received: from localhost.localdomain (mgerards.xs4all.nl [82.92.27.129]) by mail1.han.nl (Postfix) with ESMTP id 1B1F6C04B for ; Thu, 14 Apr 2005 19:05:39 +0200 (CEST) Mail-Copies-To: metgerards@student.han.nl To: The development of GRUB 2 References: <20050213165452.GA4503@miracle> <874qg5pwju.fsf@student.han.nl> <612fe64ec525dea867c45362eb985354@penguinppc.org> From: Marco Gerards Date: Thu, 14 Apr 2005 19:05:40 +0200 In-Reply-To: <612fe64ec525dea867c45362eb985354@penguinppc.org> (Hollis Blanchard's message of "Wed, 23 Feb 2005 22:40:40 -0600") Message-ID: <87br8hffvf.fsf@student.han.nl> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new (2.2.0) at vscan-cn.han.nl Subject: Re: [patch] set prefix on PPC 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, 14 Apr 2005 17:06:39 -0000 Hollis Blanchard writes: Hi Hollis, Sorry for the late reply. For some reason I did not see this email. >> You could get the property length and use that. It would be clearer. > > All these stack-based get_property calls are an accident waiting to > happen, but you've advocated them until now. :-P Instead, we need a > wrapper function that returns a malloced buffer of the proper > size. That's what you're suggesting open-coding here anyways. Using malloc is way better. > However I would rather not do that right now. The few developers > (myself included) have other things going on, and there are still > significant functionality gaps. Right now I don't want to spend time > developing patches that produce lots of code churn and no user-visible > improvement. Others are more than welcome to, of course. :) Sure, I don't have a big problem with this in this case. But please don't do that all the time because that will just make a crap out of GRUB, which is something I don't want. >> Device arguments are like the partition number or so? > > Yes. OF "node names" contain two parts, the device path and the device > arguments. The device arguments are everything following a colon, and > the syntax of the arguments is device-specific (but by convention they > are separated by commas). > > In the case of a node name like "disk:6,grubof", "6,grubof" are the > device arguments. Ok. > I used the term "device specifier" incorrectly the comments; I will > correct that. (IEEE1275 defines its terms at the beginning, which is > quite helpful...) Great. :) > As a separate issue, I *believe* that bootpath should always be a > fully-expanded node name, and so always contain a colon, but that > depends on well-behaved firmware. Accordingly, I don't think a sanity > check here is unreasonable. When dealing with some open firmware implementations, it is better to be paranoid. ;) > However, as we can see experimentally, at least Apple firmware > includes the device arguments in bootpath. My briQ's firmware does > not, at least for netbooting: > ok boot net:,grubof.chrp > grub> suspend > ok dev /chosen > ok .properties > ... > bootargs "briqboot" > bootpath "/pci@FF500000/ethernet@7" So we don't get an alias... hmm. Doesn't this cause any problems? > ... where "briqboot" is the contents of the the boot-file environment > variable. This is likely the behavior Sven said was broken. Ok.. >>> +char * >>> +grub_ieee1275_get_dev_encoding (const char *path) >>> +{ >>> + char *device = grub_ieee1275_get_devname (path); >>> + char *partition = grub_ieee1275_parse_args (path, >>> GRUB_PARSE_PARTITION); >>> + char *encoding; >>> + >>> + if (partition) >>> + { >>> + unsigned int partno = grub_strtoul (partition, 0, 0); >>> + partno--; /* GRUB partition numbering is 0-based. */ >> >> Right. But how can you be sure both match? > > Eh? OF partition numbers are 1-based. To convert to GRUB's 0-based > numbering, we subtract one. How could that not "match"? Because not in all cases GRUB and the firmware will count partitions the same way. A good example is the PC partition map. In linux primary partitions are numbers from 1 to 4, extended partitions are numbered from 5 (IIRC). One other way to count these partitions is just by starting counting from 1. This is just an example. There are a lot of partition table layouts and many ways to interpret partition numbers. I can imagine GRUB does not always work the same as a specific firmware implementation all the time. >>> + >>> + /* XXX Assume partno will only require two bytes? */ >>> + encoding = grub_malloc (grub_strlen (device) + 5); >> >> Can't you just calculate this? Otherwise you can better allocate a >> few bytes too much. > > How exactly would you like to calculate what sprintf will do before it > does it? We have no snprintf (with "sophisticated" return values), and > I don't think it's worth the effort either. > > I will change the 5 to an 8 if it makes you happy, though I would be > very surprised to see a disk with partitions in even the (base 10) > triple digits. Please do. -- Marco