On Fri, Apr 17, 2009 at 9:33 PM, Bean <bean12...@gmail.com> wrote: > Hi, > > One of the advantage of nested function is to use local variables. > Without it, we would need to pass them as global variable, or add > custom data pointer in many of the iterate function, which would make > the code a lot uglier IMO. > Do you have information in which direction it will influence the size of kernel? (trampoline vs global vs custom pointer)
> > On Fri, Apr 17, 2009 at 11:54 PM, Pavel Roskin <pro...@gnu.org> wrote: > > Hello! > > > > While I have just applied a patch adding NESTED_FUNC_ATTR to several > > functions as an emergency fix for a major breakage in ata, ohci, uhci > > and lspci modules, I would prefer a more radical solution. > > > > I suggest that we eliminate all nested functions. The reasons are: > > > > 1) They make the code less readable, as they make the parent functions > > longer. > > > > 2) They have problems with some popular compilers, as recent as gcc-4.0 > > when regparm(3) is used. > > > > 3) We failed to implement a reliable test for such problems. We are > > using regparm(1) for all compilers. > > > > 4) The existing test is one of the obstacles making it impossible to > > compile without having libc for the target (x86_64->i386 would be really > > nice), as we need to run the compiled test executable. > > > > 5) Non-i386 architectures define NESTED_FUNC_ATTR as an empty symbol, so > > developers on such architectures don't see if they use it correctly. > > > > 6) NESTED_FUNC_ATTR tends to proliferate to the file scope functions, as > > it happened with grub_pci_iterate(). It only takes one caller using a > > nested function to force NESTED_FUNC_ATTR on all functions used as an > > argument to the same function. > > > > We can give all formerly nested functions better, more descriptive names > > starting like other functions in the file and ending with "_iter". > > > > -- > > Regards, > > Pavel Roskin > > > > > > _______________________________________________ > > Grub-devel mailing list > > Grub-devel@gnu.org > > http://lists.gnu.org/mailman/listinfo/grub-devel > > > > > > -- > Bean > > > _______________________________________________ > 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
