[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Save/Load environment variable support

From: Bean
Subject: Re: [PATCH] Save/Load environment variable support
Date: Sun, 15 Jun 2008 22:09:02 +0800

On Sun, Jun 15, 2008 at 9:25 PM, Robert Millan <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]