Re: [PATCH] Converter for the new font engine
Committed. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
gettext
Hello, I was thinking to implement some kind of internalization in Grub2. We discussed some months ago, but now I have been playing with something and thinking a bit more how to do it. I have done a draft program (working, not shareable -needs some clenaup-, in standalone C) that getting a .mo file and string translates the string. I've based my implementation on: http://www.gnu.org/software/autoconf/manual/gettext/MO-Files.html (the basic one is about 200 lines) I'm not using the gettext hash table so I safe some space (in the .mo files and code), and Grub doesn't have so much strings to need the hash. Also, I'm using bisection to search a bit faster. I'm using msgmft --no-hash to not include the hash in the .mo file. * SCRIPTS (userland) We could add gettext support using external gettext program like I commented here: http://lists.gnu.org/archive/html/grub-devel/2008-12/msg00030.html or we could use the Grub2 gettext mo reader program (already implemented the basic version): so we would be testing our mo reader even in userland, and have one less dependency: gettext binary (in Debian it comes with gettext-base package). Which are your thoughts for it? * GRUB2 My idea is to create in Grub2 a function called _(...). This function will exist in standard Grub2 and return the same string that it's passed. Then I would implement a module that overwrites this function and does something like: a) get Grub2 language variable (to decide the language) b) open the language file and search for the string that the function received c) return the translation (or same string if could not be find) Thing to maybe improve: not open the .mo file everytime and read a couple of headers (just a few fseek and fread, actually) and do it only when the variable is changed. So I would need a hook to reopen the .mo file and load some .mo file information when the user changes the variable or perhaps check the previous variable value with the current one and reopen the file if it's different. Would someone do it in a different way? Which way? Thanks, -- Carles Pina i EstanyGPG id: 0x17756391 http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
fseek in Grub2
Hello, (Grub2 internal functions questions, related with gettext) I would like to use io/bufio.c to read the .mo file, so I would use grub_bufio_open to open, and grub_bufio_read to read. I'm missing grub_bufio_fseek. I think that I could play with file-offset, but this would maybe break something else (that's my guess, I have had no time to look on it). Why fseek has not been implemented? I mean, because we have not need it or because some complication? Someone used to program io/bufio.c or something else wants to take a look? Thanks a lot, PS: I like Grub2 modules, so easy to create a module and start and some new commands! -- Carles Pina i EstanyGPG id: 0x17756391 http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] fseek - fseeko
Hello,
I see in the ChangeLog that fseek() has been replaced by fseeko(). But
there still is one fseek in Grub2 that has not been changed. As far as I
can understand by mistake (should not affect anything but ChangeLog
says, about fseek, for example:
---
* util/grub-fstest.c (cmd_cmp): Use fseeko(), not fseek(). The
later is obsolete, potentially dangerous and sets a bad example.
---
So better to replace it?
ChangeLog:
--
2008-14-01 Carles Pina i Estany car...@pina.cat
* util/grub-editenv.c (main): Use fseeko(), not fseek().
--
Could someone commit it?
Thanks,
--
Carles Pina i EstanyGPG id: 0x17756391
http://pinux.info
/* grub-editenv.c - tool to edit environment block. */
/*
* GRUB -- GRand Unified Bootloader
* Copyright (C) 2008 Free Software Foundation, Inc.
*
* GRUB is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* GRUB is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with GRUB. If not, see http://www.gnu.org/licenses/.
*/
#include config.h
#include grub/types.h
#include grub/util/misc.h
#include grub/lib/envblk.h
#include stdio.h
#include unistd.h
#include string.h
#include stdlib.h
#include getopt.h
void
grub_putchar (int c)
{
putchar (c);
}
void
grub_refresh (void)
{
fflush (stdout);
}
void *
grub_term_get_current_input (void)
{
return 0;
}
void *
grub_term_get_current_output (void)
{
return 0;
}
int
grub_getkey (void)
{
return 0;
}
char *
grub_env_get (const char *name __attribute__ ((unused)))
{
return NULL;
}
static struct option options[] = {
{help, no_argument, 0, 'h'},
{version, no_argument, 0, 'V'},
{verbose, no_argument, 0, 'v'},
{0, 0, 0, 0}
};
char buffer[GRUB_ENVBLK_MAXLEN];
grub_envblk_t envblk;
static void
usage (int status)
{
if (status)
fprintf (stderr, Try ``grub-editenv --help'' for more information.\n);
else
printf (\
Usage: grub-editenv [OPTIONS] FILENAME COMMAND\n\
\n\
Tool to edit environment block.\n\
\nCommands:\n\
createcreate a blank environment block file\n\
info show information about the environment block\n\
list list the current variables\n\
set [name=value] ... change/delete variables\n\
clear delete all variables\n\
\nOptions:\n\
-h, --helpdisplay this message and exit\n\
-V, --version print version information and exit\n\
-v, --verbose print verbose messages\n\
\n\
Report bugs to %s.\n, PACKAGE_BUGREPORT);
exit (status);
}
int
create_envblk_file (char *name)
{
FILE *f;
grub_envblk_t p;
f = fopen (name, wb);
if (! f)
return 1;
/* Just in case OS don't save 0s. */
memset (buffer, -1, sizeof (buffer));
p = (grub_envblk_t) buffer[0];
p-signature = GRUB_ENVBLK_SIGNATURE;
p-length = sizeof (buffer) - sizeof (struct grub_envblk);
p-data[0] = p-data[1] = 0;
fwrite (buffer, sizeof (buffer), 1, f);
fclose (f);
return 0;
}
FILE *
open_envblk_file (char *name)
{
FILE *f;
f = fopen (name, r+b);
if (! f)
grub_util_error (Can\'t open file %s, name);
if (fread (buffer, 1, sizeof (buffer), f) != sizeof (buffer))
grub_util_error (The envblk file is too short);
envblk = grub_envblk_find (buffer);
if (! envblk)
grub_util_error (Can\'t find environment block);
return f;
}
static void
cmd_info (void)
{
printf (Envblk offset: %ld\n, (long) (envblk-data - buffer));
printf (Envblk length: %d\n, envblk-length);
}
static void
cmd_list (void)
{
auto int hook (char *name, char *value);
int hook (char *name, char *value)
{
printf (%s=%s\n, name, value);
return 0;
}
grub_envblk_iterate (envblk, hook);
}
static void
cmd_set (int argc, char *argv[])
{
while (argc)
{
char *p;
p = strchr (argv[0], '=');
if (! p)
grub_util_error (Invalid parameter);
*(p++) = 0;
if (*p)
{
if (grub_envblk_insert (envblk, argv[0], p))
grub_util_error (Environment block too small);
}
else
grub_envblk_delete (envblk, argv[0]);
argc--;
argv++;
}
}
static void
cmd_clear (void)
{
envblk-data[0] = envblk-data[1] = 0;
}
int
main (int argc, char *argv[])
{
FILE *f;
progname = grub-editenv;
/* Check for options. */
while (1)
{
int c = getopt_long (argc, argv, hVv, options, 0);
if (c == -1)
break;
else
switch (c)
{
case 'h':
usage (0);
Re: [PATCH] fseek - fseeko
On Wed, 2009-01-14 at 00:10 +0100, Carles Pina i Estany wrote: Hello, I see in the ChangeLog that fseek() has been replaced by fseeko(). But there still is one fseek in Grub2 that has not been changed. It's because grub-editenv.c appeared after the commit that eliminated fseek(). As far as I can understand by mistake (should not affect anything but ChangeLog says, about fseek, for example: --- * util/grub-fstest.c (cmd_cmp): Use fseeko(), not fseek(). The later is obsolete, potentially dangerous and sets a bad example. --- So better to replace it? It doesn't really matter when the offset is 0, but let's replace it to avoid further questions. ChangeLog: -- 2008-14-01 Carles Pina i Estany car...@pina.cat * util/grub-editenv.c (main): Use fseeko(), not fseek(). The year is placed first to make the format unambiguous. Also, string comparison would work for dates. But only if the month follows the year. Could someone commit it? Committed, a day before you posted the patch :-) Actually, you didn't post the patch. You posted the whole file. Be careful. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI Boot on MacPro
Those numbers look better. Hanging at that stage can be due to incorrect boot command - trying to boot a kernel which requires an initrd. (not the only possibility). In my case I use - linux /vmlinuz root=/dev/sda3 video=efifb initrd /initrd.img If I try to boot without initrd I get your result. On Tue, Jan 13, 2009 at 7:06 AM, Ziling Zhao zilingz...@gmail.com wrote: On Fri, Jan 9, 2009 at 4:06 PM, peter cros pxwp...@gmail.com wrote: It all seems a bit strange, [Linux-bzImage, setup=0x2c00, size=0x2ff4701] Size=50 MB - very big kernel if it is true. On Fri, Jan 9, 2009 at 5:36 PM, Bean bean12...@gmail.com wrote: On Fri, Jan 9, 2009 at 5:32 AM, Ziling Zhao zilingz...@gmail.com wrote: I haven't had much success with testing directly on the XServe that I have here, but I was able to get as far as getting grub to show up. However, it stalls after: [Linux-bzImage, setup=0x2c00, size=0x2ff4701] Video mode: 180x1050...@0 Video frame buffer: f000 Just as far as I can get the Mac Pro. I don't exactly have a macbook to test on, so I don't know if I'm just doing something wrong, or the Mac Pro/XServes are just different. Of course, using refit works on the mac pros, but applying the same process to the XServes didn't work. I've attached my .config just in case someone wants to look it over, I believe I have all the EFI stuff in there. Hi, The video mode line doesn't seem to be valid, so I guess xserver is indeed different. Fedora also have efi loader, which is basically some hacking with grub legacy. Perhaps you can try that and see if it works. -- 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 I've just checked the kernel's size, and nothing is 50MB. After fiddling, now it says. (for x86 kernel) 3.5MB [Linux-bzImage, setup=0x3000, size=0x367f70] Video mode: 1280x1024...@0 Video frame buffer: f000 The x86_64 kernel has: [Linux-bzImage, setup=0x2c00, size=0x2ff470] Video mode: 1280x1024...@0 Video frame buffer: f000 -- ~Ziling Zhao ___ 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
Re: [PATCH] fseek - fseeko
Hello, On Jan/13/2009, Pavel Roskin wrote: ChangeLog: -- 2008-14-01 Carles Pina i Estany car...@pina.cat [...] Actually, you didn't post the patch. You posted the whole file. Be careful. I will not send more patches in hurry before go to sleep :-) Thanks Pavel, -- Carles Pina i EstanyGPG id: 0x17756391 http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
