[PATCH] Making parenthesis part of word; fixes set root=(hd1,1) issue
Hi,
Recent lexer-rewrite merge into experimental has an issue, that it
rejects "set root=(hd1,1)" statement (because its not valid syntax in
BASH, which is what GRUB script was trying to emulate). Attached
patch fixes this issue, by treating parenthesis as valid word
alphabets.
--
bvk.chaitanya
=== modified file 'ChangeLog.lexer-rewrite'
--- ChangeLog.lexer-rewrite 2010-01-22 13:37:27 +
+++ ChangeLog.lexer-rewrite 2010-01-25 16:30:38 +
@@ -1,3 +1,8 @@
+2010-01-25 BVK Chaitanya
+
+ * script/yylex.l: Accept parenthesis as part of word.
+ * script/parser.y: Remove GRUB_PARSER_TOKEN_{LPAR,RPAR} tokens.
+
2010-01-10 BVK Chaitanya
* conf/any-emu.rmk: Build rule updates.
=== modified file 'script/parser.y'
--- script/parser.y 2010-01-23 04:46:05 +
+++ script/parser.y 2010-01-25 14:37:33 +
@@ -45,8 +45,6 @@
%token GRUB_PARSER_TOKEN_PIPE"|"
%token GRUB_PARSER_TOKEN_AMP "&"
%token GRUB_PARSER_TOKEN_SEMI";"
-%token GRUB_PARSER_TOKEN_LPAR"("
-%token GRUB_PARSER_TOKEN_RPAR")"
%token GRUB_PARSER_TOKEN_LBR "{"
%token GRUB_PARSER_TOKEN_RBR "}"
%token GRUB_PARSER_TOKEN_NOT "!"
=== modified file 'script/yylex.l'
--- script/yylex.l 2010-01-23 04:44:32 +
+++ script/yylex.l 2010-01-25 14:32:10 +
@@ -128,7 +128,7 @@
BLANK [ \t]
COMMENT ^[ \t]*#.*$
-CHAR[^|&$;()<> \t\n\'\"\\]
+CHAR[^|&$;<> \t\n\'\"\\]
DIGITS [[:digit:]]+
NAME[[:alpha:]_][[:alnum:][:digit:]_]*
@@ -157,8 +157,6 @@
"|" { RECORD; return GRUB_PARSER_TOKEN_PIPE;}
"&" { RECORD; return GRUB_PARSER_TOKEN_AMP; }
";" { RECORD; return GRUB_PARSER_TOKEN_SEMI;}
-"(" { RECORD; return GRUB_PARSER_TOKEN_LPAR;}
-")" { RECORD; return GRUB_PARSER_TOKEN_RPAR;}
"<" { RECORD; return GRUB_PARSER_TOKEN_LT; }
">" { RECORD; return GRUB_PARSER_TOKEN_GT; }
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Antialiased fonts patch.
Evgeny Kolesnikov wrote: > Here is the path for anti-aliased fonts. > > At first I was completely against antialiasing support because of performance impact. But it being optional decreases the later. However there is one problem: your patch relies on text_layer to be RGBA which was a mistake. RGBA for text layer is vastly inefficient especially on 16-bit framebuffer and CPUs with small cache. I had plans to switch it to indexed color. Do you really need 8bits and 4 aren't enough? If 4 are enough we could make text_layer IA44 (indexed-4 bits, alpha 4 bits) if you need 8 bits we can do IA88. I'm not sure which one is faster: firs one is more cache-efficient, second one requires less ALU. Are you interested in implementing this? > Everything my path does is: > > 1) Enriches grub-mkfont with ability to write (and debug with -vv) > pff3 (as I call it now) font format. There are 2 differences between > pff2 and pff3 formats: FILE magic (PFF2 becomes PFF3) and DATA block > entires size multiples by 8 (1bit -> 8bit). In other words PFF3 stores > 8-bit alpha channel instead of 1-bit. > And grub-mkfont will still be able to generate pff2, of course. > > And by default grub-mkfont should generate not antialiased font for performance reasons. But user or theme creator can choose to use antialiased fonts if they wish. > 2) Adds pff3 format parsing and drawing ability to font.c. > And of course pff2 still there; actually as you can understand 95% of > code is reused because of such a little differences in formats. > > Drawing itself implemented pretty straightforward: on each glyph > drawing A channel (from glyph) and foreground color are converted to > RGBA buffer and then blended in RGBA_ mode. > > As far as I understand writing custom blitter for now will not worth it > in terms of efficiency. > > > When I test it I was unable to see performance difference between 1-bit > fonts and my version. They both flickers a little. > > Files affected: /font/font.c and /util/grub-mkfont.c. > > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: macrofy fontcontants
Evgeny Kolesnikov wrote: > On Mon, 2010-01-25 at 23:07 +, Carles Pina i Estany wrote: > > >> Find attached a way to macrofy the constants from font files between >> util and grub kernel. >> >> Comments, name changes, etc. are welcomed. >> > > Can you please consider my patch for anti-aliased fonts > in your scheme. It's in the way to be added into trunk. > > (http://lists.gnu.org/archive/html/grub-devel/2010-01/msg00301.html) > > > There is no reason your pending patch should affect Carles' one. Carles: Assuming, files generated by grub-mkfont are the same up to byte and you have tested rendering part, you can merge your patch > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Antialiased fonts patch.
Hi, > At first I was completely against antialiasing support because of > performance impact. But it being optional decreases the later. However > there is one problem: your patch relies on text_layer to be RGBA > which was a mistake. RGBA for text layer is vastly inefficient > especially on 16-bit framebuffer and CPUs with small cache. I had plans > to switch it to indexed color. Do you really need 8bits and 4 aren't > enough? I use 8-bit in order to give GRUB ability to look and feel exactly as other parts of OS, so yes, 8 bits are required. If one can't allow this for his system - he can use 1-bit fonts. I don't really care about such situation just because other parts of desktop on such a system will be awful too. > If 4 are enough we could make text_layer IA44 (indexed-4 bits, > alpha 4 bits) if you need 8 bits we can do IA88. I'm not sure which one > is faster: firs one is more cache-efficient, second one requires less > ALU. Are you interested in implementing this? Actually I'm planning to add 32-bit AA (heh-heh). Sub-pixel AA for LCD monitors for complete match with xorg capabilities. And this just can't be done in indexed mode. So I can suggest to make division: 1-bit & indexed text layer vs 8(32)-bit & RGBA layer. First is for speed, second (and third) is for beauty (BURG project is already interested in - Bean, help me :)). Doing it half-way will be nor fast nor appealing. And yes, I'm interested in doing it in most effective way: blitter, optimizations etc., just give me the direction. > > Everything my path does is: > > > > 1) Enriches grub-mkfont with ability to write (and debug with -vv) > > pff3 (as I call it now) font format. There are 2 differences between > > pff2 and pff3 formats: FILE magic (PFF2 becomes PFF3) and DATA block > > entires size multiples by 8 (1bit -> 8bit). In other words PFF3 stores > > 8-bit alpha channel instead of 1-bit. > > And grub-mkfont will still be able to generate pff2, of course. > > > > > And by default grub-mkfont should generate not antialiased font for > performance reasons. But user or theme creator can choose to use > antialiased fonts if they wish. It's exactly the way my patch does it. AA is optional and used explicitly. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Antialiased fonts patch.
Evgeny Kolesnikov wrote: > Hi, > > >> At first I was completely against antialiasing support because of >> performance impact. But it being optional decreases the later. However >> there is one problem: your patch relies on text_layer to be RGBA >> which was a mistake. RGBA for text layer is vastly inefficient >> especially on 16-bit framebuffer and CPUs with small cache. I had plans >> to switch it to indexed color. Do you really need 8bits and 4 aren't >> enough? >> > > I use 8-bit in order to give GRUB ability to look and feel exactly > as other parts of OS, so yes, 8 bits are required. If one can't allow > this for his system - he can use 1-bit fonts. I don't really care about > such situation just because other parts of desktop on such a system will > be awful too. > You forget that other parts of the system have access to video acceleration capabilities, grub doesn't. > >> If 4 are enough we could make text_layer IA44 (indexed-4 bits, >> alpha 4 bits) if you need 8 bits we can do IA88. I'm not sure which one >> is faster: firs one is more cache-efficient, second one requires less >> ALU. Are you interested in implementing this? >> > > Actually I'm planning to add 32-bit AA (heh-heh). Sub-pixel AA for LCD > monitors for complete match with xorg capabilities. And this just can't > be done in indexed mode. > > So I can suggest to make division: 1-bit & indexed text layer vs > 8(32)-bit & RGBA layer. First is for speed, second (and third) > is for beauty Splitting speed/niceness is ok as long as they share most of the code and "speed" is default. Perhaps we can have a variable: set i_want_to_waste_time_in_booter=yes But before we can go to such length for beauty we would need native drivers first. No matter how you antialias if VBE accepts only 1024x768 which is stretched to 1280x800, it won't have any effect. Hence you need to port native drivers to grub. > (BURG project is already interested in - Bean, help > me :)). He is of no authority here. If something is considered harmful it will be rejected no matter what burg does. > Doing it half-way will be nor fast nor appealing. > > And yes, I'm interested in doing it in most effective way: blitter, > optimizations etc., just give me the direction. > Then you would need to consider 16-bit modes too. E.g. use RGBA5658 if screen is RGB565. > >>> Everything my path does is: >>> >>> 1) Enriches grub-mkfont with ability to write (and debug with -vv) >>> pff3 (as I call it now) font format. There are 2 differences between >>> pff2 and pff3 formats: FILE magic (PFF2 becomes PFF3) and DATA block >>> entires size multiples by 8 (1bit -> 8bit). In other words PFF3 stores >>> 8-bit alpha channel instead of 1-bit. >>> And grub-mkfont will still be able to generate pff2, of course. >>> >>> >>> >> And by default grub-mkfont should generate not antialiased font for >> performance reasons. But user or theme creator can choose to use >> antialiased fonts if they wish. >> > > It's exactly the way my patch does it. AA is optional and used > explicitly. > > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] DM-RAID probing
On Mon, Jan 25, 2010 at 07:48:46PM +, Colin Watson wrote:
> I've pushed this branch with improved DM-RAID probing support:
>
> sftp://bzr.sv.gnu.org/srv/bzr/grub/branches/dmraid-probe/
>
> This makes it possible for things like this to work:
>
> grub-probe --target=partmap --device
>
> ... which in turn makes it possible for grub-install to work when
> /boot/grub is on a DM-RAID device. The change is a bit involved, and
> requires the device-mapper userspace libraries to be effective (but I
> think these are pretty widespread). Could somebody have a look over
> this?
I've extended this so that device iteration sees DM-RAID disk devices as
well. This means that grub-mkdevicemap works (as long as you don't mind
DM-RAID disk devices showing up as "(hd2)" or similar; with UUIDs it
really doesn't matter much so I didn't go to the effort of inventing
some other namespace for them), which in turn will mean that my patch to
the Debian packaging to record the installation device using by-id paths
should work with no further changes required.
Please have a look. Proper error handling with the device-mapper
libraries winds up being a bit verbose, but I tried to make it as
readable as I could.
=== added file 'ChangeLog.dmraid-probe'
--- ChangeLog.dmraid-probe 1970-01-01 00:00:00 +
+++ ChangeLog.dmraid-probe 2010-01-26 14:26:09 +
@@ -0,0 +1,26 @@
+2010-01-26 Colin Watson
+
+ * configure.ac: Check for Linux device-mapper support.
+
+ * util/hostdisk.c (device_is_mapped): New function.
+ (find_partition_start): New function, partly broken out from
+ linux_find_partition and grub_util_biosdisk_get_grub_dev but with
+ device-mapper support added.
+ (linux_find_partition): Use find_partition_start.
+ (convert_system_partition_to_system_disk): Add `st' argument.
+ Support Linux /dev/mapper/* devices if device-mapper support is
+ available; only DM-RAID devices are understood at present.
+ (find_system_device): Add `st' argument. Pass it to
+ convert_system_partition_to_system_disk.
+ (grub_util_biosdisk_get_grub_dev): Pass stat result to
+ find_system_device and convert_system_partition_to_system_disk. Use
+ find_partition_start.
+
+ * conf/common.rmk (grub_mkdevicemap_SOURCES): Add kern/env.c,
+ kern/err.c, kern/list.c, and kern/misc.c.
+ * util/deviceiter.c [__linux__]: Define MINOR.
+ (grub_util_iterate_devices): Add support for DM-RAID disk devices.
+ * util/mkdevicemap.c (grub_putchar): New function.
+ (grub_getkey): New function.
+ (grub_refresh): New function.
+ (main): Set debug=all if -v -v is used.
=== modified file 'conf/common.rmk'
--- conf/common.rmk 2010-01-20 20:31:39 +
+++ conf/common.rmk 2010-01-26 14:21:28 +
@@ -3,7 +3,8 @@
sbin_UTILITIES += grub-mkdevicemap
grub_mkdevicemap_SOURCES = gnulib/progname.c util/grub-mkdevicemap.c \
util/deviceiter.c \
- util/misc.c
+ util/misc.c \
+ kern/env.c kern/err.c kern/list.c kern/misc.c
ifeq ($(target_cpu)-$(platform), sparc64-ieee1275)
grub_mkdevicemap_SOURCES += util/ieee1275/ofpath.c util/ieee1275/devicemap.c
=== modified file 'configure.ac'
--- configure.ac2010-01-25 09:06:55 +
+++ configure.ac2010-01-25 16:40:40 +
@@ -659,6 +659,23 @@ AC_SUBST([enable_grub_mkfont])
AC_SUBST([freetype_cflags])
AC_SUBST([freetype_libs])
+AC_ARG_ENABLE([device-mapper],
+ [AS_HELP_STRING([--enable-device-mapper],
+ [enable Linux device-mapper support
(default=guessed)])])
+if test x"$enable_device_mapper" = xno ; then
+ device_mapper_excuse="explicitly disabled"
+fi
+
+if test x"$device_mapper_excuse" = x ; then
+ # Check for device-mapper library.
+ AC_CHECK_LIB([devmapper], [dm_task_create],
+ [LDFLAGS="$LDFLAGS -ldevmapper"
+AC_DEFINE([HAVE_DEVICE_MAPPER], [1],
+ [Define to 1 if you have the devmapper library.])],
+ [device_mapper_excuse="need devmapper library"])
+ AC_SUBST([LIBDEVMAPPER])
+fi
+
AC_SUBST(ASFLAGS)
# Output files.
=== modified file 'util/deviceiter.c'
--- util/deviceiter.c 2009-07-29 14:11:50 +
+++ util/deviceiter.c 2010-01-26 14:22:50 +
@@ -31,6 +31,8 @@
#include
#include
+#include
+#include
#ifdef __linux__
# if !defined(__GLIBC__) || \
@@ -62,12 +64,23 @@ struct hd_geometry
| ((unsigned int) (__dev >> 32) & ~0xfff); \
})
# endif /* ! MAJOR */
+# ifndef MINOR
+# define MINOR(dev) \
+ ({ \
+ unsigned long long __dev = (dev); \
+ (unsigned) (__dev & 0xff) | ((unsigned int) (__dev >> 12) & ~0xff); \
+ })
+# endif /* ! MINOR */
# ifndef CDROM_GET_CAPABILITY
# define CDROM_GET_CAPABILITY 0x5331 /* get capabilities */
# endif /* ! CDROM_GET_CAPABILITY */
# ifndef BLKGETSIZE
# define BLKGETSIZE _IO(0x12,96)/* return device size */
#
Re: On gratuitous modularization
On Mon, Jan 25, 2010 at 09:13:11PM +0100, Christian Franke wrote: > > The module ata_pthru.mod exists only to keep ata.mod small, see: > http://lists.gnu.org/archive/html/grub-devel/2009-02/msg00091.html I see. Thanks for pointing this out. > Keeping the ata.mod specific pass-through function separate from > hdparm.mod was intentional. Merging this function into hdparm.mod would > only make sense if ata.mod will the only ATA access module with > pass-through functionality in the future. Note that linking ata_pthru.c into hdparm.mod doesn't prevent this code from being linked into other modules if/when the need arises. But right now, it's only used by hdparm. I see little justification in having a separate module in this situation. I'm inclined to merge it. > BTW: I agree that using a global function pointer > 'grub_disk_ata_pass_through' is a hack. A cleaner design would be > possible with a grub_disk_dev.ioctl(.) call. The problem I see with 'grub_disk_ata_pass_through' is that it shouldn't be in kernel. The interface itself is less relevant IMO. -- Robert Millan "Be the change you want to see in the world" -- Gandhi ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
PXE directory listing incorrectly reported as "success"
Hi, It appears that directory listing isn't supported by TFTP protocol (so says our wiki). Our pxe.c implements grub_pxefs_dir() as a dummy stub that returns GRUB_ERR_NONE. This is obviously wrong, as it prevents the user from noticing that there was a problem, and silently reports an "empty" directory. Instead, it should call grub_error (). Unfortunately, kern/fs.c relies on grub_pxefs_dir() returning GRUB_ERR_NONE in order to consider probing to be succesful. If pxe returned an error, it wouldn't be considered a valid filesystem by the kernel. So I'm wondering, what would be a good solution to this? We could add a proper probe() function and switch all filesystems to it, but only for the benefit of pxe it seems a bit overkill. Does someone have a better idea? -- Robert Millan "Be the change you want to see in the world" -- Gandhi ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: PXE directory listing incorrectly reported as "success"
How about returning one entry named 'pxe/tftp doesn't support directory listing' :). --S On Jan 26, 2010, at 12:08 PM, Robert Millan wrote: Hi, It appears that directory listing isn't supported by TFTP protocol (so says our wiki). Our pxe.c implements grub_pxefs_dir() as a dummy stub that returns GRUB_ERR_NONE. This is obviously wrong, as it prevents the user from noticing that there was a problem, and silently reports an "empty" directory. Instead, it should call grub_error (). Unfortunately, kern/fs.c relies on grub_pxefs_dir() returning GRUB_ERR_NONE in order to consider probing to be succesful. If pxe returned an error, it wouldn't be considered a valid filesystem by the kernel. So I'm wondering, what would be a good solution to this? We could add a proper probe() function and switch all filesystems to it, but only for the benefit of pxe it seems a bit overkill. Does someone have a better idea? -- Robert Millan "Be the change you want to see in the world" -- Gandhi ___ 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: Antialiased fonts patch.
Hi, On Jan/26/2010, Vladimir '??-coder/phcoder' Serbinenko wrote: > Evgeny Kolesnikov wrote: > > So I can suggest to make division: 1-bit & indexed text layer vs > > 8(32)-bit & RGBA layer. First is for speed, second (and third) > > is for beauty > Splitting speed/niceness is ok as long as they share most of the code > and "speed" is default. how much slower would be? (just for curiosity). 10 ms per screen or 20 seconds? > Perhaps we can have a variable: > set i_want_to_waste_time_in_booter=yes I suggest "set i_want_high_quality_fonts=yes" (well, withought i_want). I would say that mainly everybody knows that "high quality something" usually has some payback. > But before we can go to such length for beauty we would need native > drivers first. No matter how you antialias if VBE accepts only > 1024x768 which is stretched to 1280x800, it won't have any effect. > Hence you need to port native drivers to grub. I understand and agree. -- Carles Pina i Estany http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: macrofy fontcontants
Hi, On Jan/26/2010, Vladimir '??-coder/phcoder' Serbinenko wrote: > Evgeny Kolesnikov wrote: > > On Mon, 2010-01-25 at 23:07 +, Carles Pina i Estany wrote: > > > > > >> Find attached a way to macrofy the constants from font files between > >> util and grub kernel. > >> > >> Comments, name changes, etc. are welcomed. > >> > > > > Can you please consider my patch for anti-aliased fonts > > in your scheme. It's in the way to be added into trunk. > > > > (http://lists.gnu.org/archive/html/grub-devel/2010-01/msg00301.html) > > > > > > > There is no reason your pending patch should affect Carles' one. Well, someone has to adapt some code :-( It was on my pending list for some weeks... bad timing. But your one Evgeny is a bit bigger and may take some time > Carles: Assuming, files generated by grub-mkfont are the same up to byte > and you have tested rendering part, you can merge your patch I will double check and commit. Thanks, -- Carles Pina i Estany http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Multiboot's boot_device field specification + implementation bug
Hi, (a) set root=(hd1,2,a) ; multiboot /mbtest ; boot --> boot_device = 0x810100ff (b) multiboot (hd1,2,a)/mbtest ; boot --> boot_device = 0x8000 Out of curiosity, I tried equivalent commands with GRUB Legacy, and I get boot_device = 0x810100ff in both cases. Best regards, Grégoire ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] support for xz compression format
Hello, Attached patch adds support for xz compressed files. Interface is similar to gzio: grub_xzio_open() and grub_xzfile_open(). Files: xzio.h and xzio.c Decompression algorithm is imported (no source code changes) from http://tukaani.org/xz/embedded.html and is located in lib/xzembed directory (files xz_* except xz_wrap.h which is a glue header) XZ embedded supports only crc32 integration check so if You want to test it use `xz --check=crc32` to compress, It also supports BCJ filters (not enabled with this patch) so it is possible to get extra few % compression ratio with executables. known issues: - decoder dictionary size is hardcoded, discovery at runtime would be better (it's on my TODO list) - grub_file_seek() will break reading (not a big deal, xz streams are not seekable afterall, if needed should be possible to implement but will cause read performance penatly) Suggestions and comments are welcome :-) -- Szymon K. Janc szy...@janc.net.pl // GG: 1383435 xzio.diff.bz2 Description: application/bzip ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] support for xz compression format
Szymon Janc wrote: > Hello, > > Attached patch adds support for xz compressed files. Interface is similar to > gzio: grub_xzio_open() and grub_xzfile_open(). Files: xzio.h and xzio.c > > Decompression algorithm is imported (no source code changes) from > http://tukaani.org/xz/embedded.html and is located in lib/xzembed directory > (files xz_* except xz_wrap.h which is a glue header) > > XZ embedded supports only crc32 integration check so if You want to test it > use `xz --check=crc32` to compress, It also supports BCJ filters (not > enabled > with this patch) so it is possible to get extra few % compression ratio with > executables. > How does xz with and without BCJ performs for i386 code? Perhaps we would want to replace lzma with xz for core.img compression. > known issues: > - decoder dictionary size is hardcoded, discovery at runtime would be better > (it's on my TODO list) > Can't grub_realloc be used for this? > - grub_file_seek() will break reading (not a big deal, xz streams are not > seekable afterall, if needed should be possible to implement but will cause > read performance penatly) > I see no reason to have xzembed.mod separate from xzio.mod. It should be all in xzio.mod and use common.rmk and not xzembed.rmk. + static grub_uint8_t inbuf[XZBUFSIZ]; + static grub_uint8_t outbuf[XZBUFSIZ]; Will break if 2 files are opened in the same time. + grub_error (GRUB_ERR_OUT_OF_MEMORY, "out of memory"); No need for this (already done by grub_malloc) + if (transparent) + return io; + else + return 0; You need to discard or pass any pending errors + grub_free (xzio); + file->device = 0; + Why do you set device to 0? --- grub2-1.98~experimental.20100120/lib/xzembed/xz_crc32.c 2010-01-20 21:42 :33.0 +0100 We already have 2 CRC32 implementations: one in libgcrypt import and one in crc32.mod. This code duplication is undesirable. I have plans to remove crc32.mod in favor of libgcrypt implementation. Can you make xz use libgcrypt import too? + #include I think gnulib-wrap has to be splitted into gnulib-wrap and posix-wrap + #define uint8_t grub_uint8_t + #define uint16_t grub_uint16_t + #define uint32_t grub_uint32_t + #define uint64_t grub_uint64_t typedef is more appropriate > > Suggestions and comments are welcome :-) > > > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: PXE directory listing incorrectly reported as "success"
Robert Millan wrote: > Hi, > > It appears that directory listing isn't supported by TFTP protocol (so > says our wiki). > > Our pxe.c implements grub_pxefs_dir() as a dummy stub that returns > GRUB_ERR_NONE. This is obviously wrong, as it prevents the user from > noticing that there was a problem, and silently reports an "empty" > directory. Instead, it should call grub_error (). > > Unfortunately, kern/fs.c relies on grub_pxefs_dir() returning > GRUB_ERR_NONE in order to consider probing to be succesful. If pxe > returned an error, it wouldn't be considered a valid filesystem by > the kernel. > > So I'm wondering, what would be a good solution to this? What about return GRUB_ERR_UNSUPPORTED or a separate GRUB_ERR_FS_NO_DIR which would be ignored by probing routines? > We could add > a proper probe() function and switch all filesystems to it, but only > for the benefit of pxe it seems a bit overkill. > > Does someone have a better idea? > > -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
gettext util/*
Hi,
Here is the first patch to gettextizze strings in util/* (well, before
some things has been done).
Vladimir suggested to not gettext:
+ printf (_("\nGlyph #%d, U+%04x\n"), num, glyph->char_code);
+ printf (_("Width %d, Height %d, X offset %d, Y offset %d, Device
width %d\n"),
I'm fine to leave it out.
It gettexts mainly everything but not grub_util_error / grub_util_info
calls, waiting how we handle it (to be discussed later in another
thread).
Any feedback?
Thanks,
--
Carles Pina i Estany
http://pinux.info
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: gettext util/*
On Jan/27/2010, Carles Pina i Estany wrote:
>
> Hi,
>
> Here is the first patch to gettextizze strings in util/* (well, before
> some things has been done).
Now with the patch attached.
--
Carles Pina i Estany
http://pinux.info
=== modified file 'ChangeLog'
--- ChangeLog 2010-01-26 21:23:59 +
+++ ChangeLog 2010-01-26 22:26:23 +
@@ -1,4 +1,20 @@
2010-01-26 Carles Pina i Estany
+
+ * util/grub-editenv.c: Gettextizze mainly all user interface strings
+ excepting grub_util_info or grub_util_error.
+ * util/grub-emu.c: Likewise.
+ * util/grub-fstest.c: Likewise.
+ * util/grub-macho2img.c: Likewise.
+ * util/grub-mkdevicemap.c: Likewise.
+ * util/grub-mkfont.c: Likewise.
+ * util/grub-mkpasswd-pbkdf2.c: Likewise.
+ * util/grub-mkrelpath.c: Likewise.
+ * util/grub-pe2elf.c: Likewise.
+ * util/grub-probe.c: Likewise.
+ * util/grub-script-check.c: Likewise.
+ * po/POTFILES: Add gettextizzed files.
+
+2010-01-26 Carles Pina i Estany
* util/bin2h.c (usage): Fix warning (space after backslash).
=== modified file 'po/POTFILES'
--- po/POTFILES 2010-01-21 08:04:49 +
+++ po/POTFILES 2010-01-26 22:17:33 +
@@ -77,5 +77,17 @@ normal/misc.c
term/serial.c
+util/grub-editenv.c
+util/grub-emu.c
+util/grub-fstest.c
+util/grub-macho2img.c
+util/grub-mkdevicemap.c
+util/grub-mkfont.c
+util/grub-mkpasswd-pbkdf2.c
util/grub-mkrawimage.c
+util/grub-mkrelpath.c
+util/grub-pe2elf.c
+util/grub-probe.c
+util/grub-probe.c
+util/grub-script-check.c
util/i386/pc/grub-setup.c
=== modified file 'util/grub-editenv.c'
--- util/grub-editenv.c 2010-01-16 00:39:14 +
+++ util/grub-editenv.c 2010-01-26 22:05:13 +
@@ -69,9 +69,9 @@ static void
usage (int status)
{
if (status)
-fprintf (stderr, "Try `%s --help' for more information.\n", program_name);
+fprintf (stderr, _("Try `%s --help' for more information.\n"), program_name);
else
-printf ("\
+printf (_("\
Usage: %s [OPTIONS] [FILENAME] COMMAND\n\
\n\
Tool to edit environment block.\n\
@@ -87,7 +87,7 @@ Tool to edit environment block.\n\
\n\
If not given explicitly, FILENAME defaults to %s.\n\
\n\
-Report bugs to <%s>.\n",
+Report bugs to <%s>.\n"),
program_name, DEFAULT_DIRECTORY "/" GRUB_ENVBLK_DEFCFG, PACKAGE_BUGREPORT);
exit (status);
@@ -287,7 +287,7 @@ main (int argc, char *argv[])
/* Obtain the filename. */
if (optind >= argc)
{
- fprintf (stderr, "no filename specified\n");
+ fprintf (stderr, _("no filename specified\n"));
usage (1);
}
@@ -312,7 +312,7 @@ main (int argc, char *argv[])
unset_variables (filename, argc - optind - 2, argv + optind + 2);
else
{
- fprintf (stderr, "unknown command %s\n", command);
+ fprintf (stderr, _("unknown command %s\n"), command);
usage (1);
}
=== modified file 'util/grub-emu.c'
--- util/grub-emu.c 2010-01-16 00:39:14 +
+++ util/grub-emu.c 2010-01-26 22:06:02 +
@@ -129,10 +129,10 @@ usage (int status)
{
if (status)
fprintf (stderr,
- "Try `%s --help' for more information.\n", program_name);
+ _("Try `%s --help' for more information.\n"), program_name);
else
printf (
- "Usage: %s [OPTION]...\n"
+_("Usage: %s [OPTION]...\n"
"\n"
"GRUB emulator.\n"
"\n"
@@ -144,7 +144,7 @@ usage (int status)
" -h, --helpdisplay this message and exit\n"
" -V, --version print version information and exit\n"
"\n"
- "Report bugs to <%s>.\n", program_name, DEFAULT_DEVICE_MAP, DEFAULT_DIRECTORY, PACKAGE_BUGREPORT);
+ "Report bugs to <%s>.\n"), program_name, DEFAULT_DEVICE_MAP, DEFAULT_DIRECTORY, PACKAGE_BUGREPORT);
return status;
}
@@ -191,13 +191,13 @@ main (int argc, char *argv[])
if (optind < argc)
{
- fprintf (stderr, "Unknown extra argument `%s'.\n", argv[optind]);
+ fprintf (stderr, _("Unknown extra argument `%s'.\n"), argv[optind]);
return usage (1);
}
/* Wait until the ARGS.HOLD variable is cleared by an attached debugger. */
if (hold && verbosity > 0)
-printf ("Run \"gdb %s %d\", and set ARGS.HOLD to zero.\n",
+printf (_("Run \"gdb %s %d\", and set ARGS.HOLD to zero.\n"),
program_name, (int) getpid ());
while (hold)
{
=== modified file 'util/grub-fstest.c'
--- util/grub-fstest.c 2010-01-20 08:12:47 +
+++ util/grub-fstest.c 2010-01-26 22:07:18 +
@@ -367,9 +367,9 @@ static void
usage (int status)
{
if (status)
-fprintf (stderr, "Try `%s --help' for more information.\n", program_name);
+fprintf (stderr, _("Try `%s --help' for more information.\n"), program_name);
else
-printf ("\
+printf (_("\
Usage: %s [OPTION]... IMAGE_PATH COMMANDS\n\
\n\
Debug tool for filesystem driver.\n\
@@ -390,7 +390,7 @@ Debug tool for filesystem driver.\n\
-V, --version print version information and exit\n\
-v, --verbose print verbose messages\n\
\n\
-Report bugs to <%
