All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] Save/Load environment variable support
Date: Sun, 15 Jun 2008 15:25:52 +0200	[thread overview]
Message-ID: <20080615132552.GA17222@thorin> (raw)
In-Reply-To: <ca0f59980806141244t6ed39f11x7768c1cbd8105472@mail.gmail.com>

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 /.)



  reply	other threads:[~2008-06-15 13:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-13  7:07 [PATCH] Save/Load environment variable support Bean
2008-06-14 18:47 ` Robert Millan
2008-06-14 19:03   ` Bean
2008-06-14 19:20     ` Robert Millan
2008-06-14 19:28       ` Bean
2008-06-14 19:30 ` Robert Millan
2008-06-14 19:44   ` Bean
2008-06-15 13:25     ` Robert Millan [this message]
2008-06-15 14:09       ` Bean
2008-06-30 13:06         ` Bean
2008-07-01 15:54           ` Robert Millan
2008-07-02  7:39             ` Bean
2008-07-03 18:04               ` Marco Gerards
2008-07-03 18:09                 ` Pavel Roskin
2008-07-03 20:11                   ` Bean
2008-07-03 22:52                     ` Robert Millan
2008-07-03 20:41                   ` Marco Gerards
2008-07-03 21:06                     ` Bean

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080615132552.GA17222@thorin \
    --to=rmh@aybabtu.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.