[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Save/Load environment variable support
From: |
Robert Millan |
Subject: |
Re: [PATCH] Save/Load environment variable support |
Date: |
Sun, 15 Jun 2008 15:25:52 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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.
> >> + 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.
--
Robert Millan
<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)