From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MF9hi-0008KT-MX for mharc-grub-devel@gnu.org; Fri, 12 Jun 2009 12:34:10 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MF9hh-0008KD-Ci for grub-devel@gnu.org; Fri, 12 Jun 2009 12:34:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MF9hc-0008Iu-7P for grub-devel@gnu.org; Fri, 12 Jun 2009 12:34:08 -0400 Received: from [199.232.76.173] (port=51007 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MF9hc-0008Iq-0E for grub-devel@gnu.org; Fri, 12 Jun 2009 12:34:04 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]:57964) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MF9hY-000052-Or for grub-devel@gnu.org; Fri, 12 Jun 2009 12:34:03 -0400 Received: from [85.180.50.238] (e180050238.adsl.alicedsl.de [85.180.50.238]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MKv5w-1MF9hU2HWg-0001oK; Fri, 12 Jun 2009 18:33:56 +0200 From: Felix Zielcke To: The development of GRUB 2 In-Reply-To: <1244823714.9051.42.camel@mj> References: <1241620317.3746.8.camel@fz.local> <1243885166.3417.11.camel@fz.local> <1244496026.3833.37.camel@fz.local> <1244674821.8525.23.camel@fz.local> <1244762505.3552.64.camel@fz.local> <1244762744.3552.65.camel@fz.local> <1244802503.3181.0.camel@fz.local> <1244823714.9051.42.camel@mj> Content-Type: text/plain Date: Fri, 12 Jun 2009 18:33:55 +0200 Message-Id: <1244824435.3181.16.camel@fz.local> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/KXIKJRxkocVnTNZm1s0GWg4dhJ2RnUAtCo7c x7AIgHMwh2h1kj8ygm1XNgfp6NMuPLg68gwInvjUP1LA2olUEj vjKYkn+OqVmJ8R6Zh3TUA== X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: [PATCH] Re: grub-install --root-directory=/mnt /dev/sda1 fails 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: Fri, 12 Jun 2009 16:34:09 -0000 Am Freitag, den 12.06.2009, 12:21 -0400 schrieb Pavel Roskin: > On Fri, 2009-06-12 at 12:28 +0200, Felix Zielcke wrote: > > > Ok here's a new one which compiles without warnings. > > I suggest that whenever a patch is published, it comes with a detailed > description. Surely, it could be gathered by rereading the thread, but > I think it's not sufficient for two reasons. > > The first reason is that we want the patches reviewed by more people. > Not everybody has time to read the whole discussion. > > The second reason is that the description the shows how the author sees > the changes, what the potential benefits are, what code is affected. > The reviewers would be able to compare the goals to the implementation. > > Even if the description was already published, it should not be hard to > publish it again, perhaps with some improvements. Well it does (well should) exactly do the same as the make_system_path_relative_to_its_root in util/grub-mkconfig_lib except that it's written in C instead of a bash function. > Regarding this patch, I don't think we need to add a function to > hostdisk.c is it's only used in grub-setup.c. It would be better to > have it in grub-setup.c unless it's a generic function or there is a > good chance that it will be used elsewhere. > > grub_make_system_path_relative_to_its_root is a very long name. There > is nothing wrong with a long name per se, but it may be in sign that the > function is too specialized and should not be in hostdisk.c. > > Following is not good for several reasons: > > #warning "The function `grub_make_system_path_relative_to_its_root' > might not work on your OS correctly." > > The warning will only be seen by those who compile GRUB, but not by the > end users who installed a binary. The warning doesn't explain what > exactly may not work correctly. Since we are talking about new > functionality here, I'd rather omit an unsafe implementation if > realpath() is not available. > > What is free_ptr? It looks like it's a pointer that the caller should > free. I think functions should be self-contained and should not ask the > caller to do the cleanup (unless they actually return something useful > in the allocated memory). Robert anyway already said that this needs discussing. The function is currently only useful in grub-setup in the case blocklists are used for core.img I don't think it will be useful for anything else. About free_ptr, yeah I could just copy buf2 + offset to a buf3 and then just free buf2 inside the function so that the caller can just free the return value of it. But I got this idea only after I sent the patch and I already told Vladimir that he doestn't need to look anymore because Robert wants to have the whole design discussed first. -- Felix Zielcke