From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LvaFi-0003fk-6u for mharc-grub-devel@gnu.org; Sun, 19 Apr 2009 12:52:22 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LvaFg-0003eZ-Mt for grub-devel@gnu.org; Sun, 19 Apr 2009 12:52:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LvaFb-0003dB-LY for grub-devel@gnu.org; Sun, 19 Apr 2009 12:52:19 -0400 Received: from [199.232.76.173] (port=59633 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LvaFb-0003d8-Ir for grub-devel@gnu.org; Sun, 19 Apr 2009 12:52:15 -0400 Received: from ti-out-0910.google.com ([209.85.142.186]:53941) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LvaFa-0000KR-T9 for grub-devel@gnu.org; Sun, 19 Apr 2009 12:52:15 -0400 Received: by ti-out-0910.google.com with SMTP id b6so1009291tic.10 for ; Sun, 19 Apr 2009 09:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=DIw25UXGFn8e0uZep9c+b3VDNe5CL/zwJkctdSdzNqE=; b=sis9jm2Le9xvqNAZhMDvesablVknILX+iqezdFetjjo+6u2vD/9MjRlqS/sX2gs3Ek DlQR1r7Q3XYlHHuyPf1XI3732kW7ySgpJciPksy4ulfZYWLYirYWR0Xt8hcxFlpadlJV V/2lI1GpOLQfHCl2/EnBZDM4VwyHVkE18/3PA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=m7YvaFFFRySo0zxNXHHF71Fk/1hB7+hoLsFjTmm6gm5RFl25S/aT64JJTJfqYZG6nh xPQL9hR4MpiU+IWeXOH9ddlnwC21GWFwbbANZlDMMCU9xpxLjgAkbVIVwo9sSofPc0dG fvSveAx1kp175Gx7gD5aCENjGIL3s4T96zKSc= MIME-Version: 1.0 Received: by 10.110.61.16 with SMTP id j16mr5240463tia.23.1240159933075; Sun, 19 Apr 2009 09:52:13 -0700 (PDT) In-Reply-To: References: <1239983697.4383.15.camel@mj> <1240004288.9057.5.camel@mj> <20090419102958.tfy97u7lc8400c4c-cebfxv@webmail.spamcop.net> Date: Mon, 20 Apr 2009 00:52:12 +0800 Message-ID: From: Bean To: The development of GRUB 2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Eliminating nested functions 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, 19 Apr 2009 16:52:21 -0000 Hi, Right, we can wrap the local variables in void* and pass them in a custom pointer, but I still think it's advantageous to put them in a structure rather than use multiple parameters: 1, We can still use nested function. Sometimes it may seem tedious to use external function for simple callback function. IMO, nested function is not that bad, we just have to use it safely. 2. It's extensible. For example, we may need to add new information for the hook function (such as adding modification time for dir hook). With the structure pointer, we just need to add a new field, old code that doesn' t use this information doesn't need to change. With parameters, we need to change the definition of all callback function, and the numerous __attribute__ ((unused)) is not pretty either. On Sun, Apr 19, 2009 at 10:51 PM, Vladimir Serbinenko w= rote: > In my opinion a far better way would be to add an additional void * argum= ent > which is passed unchanged to the hook. Like: > > struct local > { > =A0=A0 ... > }; > > main_func () > { > struct local locvars; > > grub_*_iterate (arg1,arg2,arg3, &locvars); > } > > hook (arg1, arg2, arg3, voidparg) > { > struct local *locvars =3D (struct local *) voidparg; > > } > > On Sun, Apr 19, 2009 at 4:29 PM, Pavel Roskin wrote: >> >> Quoting Bean : >> >>> Yeah, I agree with you. The conversion will take some effort, but it >>> could payoff in the long run. Perhaps we can achieve this in two >>> steps: >>> >>> 1, Change nested function definition to accept only one parameter. For >>> function with multiple parameters, place them in a structure and pass >>> the pointer. This would eliminate NESTED_FUNC_ATTR, as the regparm >>> issue won't occur in function with only one parameter. >>> >>> 2. Eliminate nested function. This would be easier after step 1. As we >>> now pass parameters in a structure, we can append extra variables at >>> the end, and cast it to the required type. Inside the callback >>> function, we cast it back to use the extra fields. >> >> That's an excellent plan! =A0Thank you! >> >> Considering the amount of changes, it may be a good idea to use the git >> mirror with stgit, so that several patches can be made and everything is >> well tested together before applying. >> >> -- >> Regards, >> Pavel Roskin >> >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/grub-devel > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > --=20 Bean