On Sun, Jun 15, 2008 at 9:25 PM, Robert Millan <[EMAIL PROTECTED]> wrote: > On Sun, Jun 15, 2008 at 03:44:56AM +0800, Bean wrote: >> >> +#define grub_strlen strlen >> >> +#define grub_strcpy strcpy >> >> +#define grub_strchr strchr >> >> +#define grub_memcmp memcmp >> >> +#define grub_memcpy memcpy >> > >> > Uhm can we avoid this? The rest of non-util code just calls the grub_* >> > functions (linking with kern/misc.c in this case). >> >> I fount out that if I use grub_*, I end up adding quite a few of extra >> modules that serve no purpose other than string manipulation. Perhaps >> we should separate those routines from kern/misc.c ? > > Which modules? If these functions are part of kernel, they shouldn't be > dragging modules in, AFAICT.
Oh, I actually means the files, in kern/misc.c, there is reference to other function, which requires other unrelated files to be included. > >> >> + for (len = GRUB_ENVBLK_MAXLEN - 6; len > 0; len -= 4, pd++) >> >> + if (*pd == GRUB_ENVBLK_SIGNATURE) >> > >> > I wonder if this would be dangerous when run on files where env block >> > presence is optional, like core.img (though we can always think about this >> > later when that option is added). >> >> Yes, perhaps we should store a pointer to environment block so that we >> don't need to scan for it. > > If the env block could have variable length (in core.img, not the filesystem > one), then maybe a zero-length block could be embedded unconditionaly. It can have zero length. The len variable is used to count the distant to the end of buffer. -- Bean _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
