opening new context (was: [PATCH] allow user-configurable menucolor)
On Thu, Jan 03, 2008 at 06:04:59PM +0200, Vesa Jääskeläinen wrote: About new context: Shouldn't new context have clone of it's parent contexts settings? I wouldn't want to change that without having some input from whoever designed (or understands) grub_env_export(). There's probably a reason for it, although I can't see it. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-fstest: debug tool for filesystem driver
On Thu, Jan 03, 2008 at 01:11:32AM +0800, Bean wrote: blst FILE display the blocklist of FILE in the image file Is this `blst' analogous to the `blocklist' command we already have? In that case, I'd suggest giving it the same name. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-fstest: debug tool for filesystem driver
On Jan 4, 2008 7:53 PM, Robert Millan [EMAIL PROTECTED] wrote: On Thu, Jan 03, 2008 at 01:11:32AM +0800, Bean wrote: blst FILE display the blocklist of FILE in the image file Is this `blst' analogous to the `blocklist' command we already have? In that case, I'd suggest giving it the same name. yep, it's the same. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] skip `.' and `..' directories in TAB completion
This patch skips . and .. directories in tab completion. They're basicaly
useless to the user, and this mimics bash completion behaviour.
--
Robert Millan
GPLv2 I know my rights; I want my phone call!
DRM What use is a phone call, if you are unable to speak?
(as seen on /.)
* normal/completion.c (iterate_dir): Skip `.' and `..' directories.
diff -urp -x CVS grub2/normal/completion.c grub2.completion/normal/completion.c
--- grub2/normal/completion.c 2007-09-03 22:28:24.0 +0200
+++ grub2.completion/normal/completion.c 2008-01-04 13:11:49.0 +0100
@@ -138,7 +138,7 @@ iterate_dir (const char *filename, int d
if (add_completion (filename, prefix, GRUB_COMPLETION_TYPE_FILE))
return 1;
}
- else
+ else if (grub_strcmp (filename, .) grub_strcmp (filename, ..))
{
char fname[grub_strlen (filename) + 2];
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Fri, Jan 04, 2008 at 01:32:24PM +0100, Robert Millan wrote: (we already work this out mostly by heuristics e.g. see my commit in 2007-10-07). Erm sorry, this part is not accurate. What I mean is that we use heuristics when firmware is buggy and its /memory/available OFW path doesn't represent actual memory availability. This is probably the case here. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
At Sat, 22 Dec 2007 09:28:28 +0100, Yoshinori K. Okuji wrote: On Tuesday 18 December 2007 13:05, Otavio Salvador wrote: Personally I don't like bazaar due performance problem. It's really slow for big projects (it wouldn't be a big problem since GRUB is a small one) and it changes its data format too ofthen. Hmm, I thought they have fixed the performance issues already? About the data format, I have no idea. jbailey, do you have any comment? ;) I've used bzr when working on my summer of code project 1.5 years ago and didn't have any issues with performance. And this was before they did all the performance improvements. Maybe with big source trees like Linux it's still too slow, but for GRUB this is really no problem. The changes in data format shouldn't really be any problem in practice, because newer versions can still read the older disk format and the network protocol doesn't change most of the time. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] split realmode and loader routines out of startup.S
At Tue, 16 Oct 2007 23:09:07 +0200, Robert Millan wrote: This patch splits realmode and loader routines out of startup.S. The idea is that the LinuxBIOS port can be adapted to share more code with the rest of GRUB instead of duplicating it. This is quite critical stuff, so even if the change seems trivial I'd suggest being careful, since I don't trust myself too much. Of course, I've tested that it can still boot Linux and Multiboot (on qemu only). Perhaps testing on real hardware would be appropiate (but I don't have this handy atm). SNIP * kern/i386/pc/startup.S (protstack): Moved to ... * kern/i386/realmode.S (protstack): ... here. * kern/i386/pc/startup.S (gdt): Moved to ... * kern/i386/realmode.S (gdt): ... here. * kern/i386/pc/startup.S (prot_to_real): Moved to ... * kern/i386/realmode.S (prot_to_real): ... here. * kern/i386/pc/startup.S: Include `kern/i386/loader.S' and `kern/i386/realmode.S'. Why did you move prot_to_real to realmode.S, but not real_to_prot? That seems a bit strange to me... Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
Jeroen Dekkers [EMAIL PROTECTED] writes: At Sat, 22 Dec 2007 09:28:28 +0100, Yoshinori K. Okuji wrote: On Tuesday 18 December 2007 13:05, Otavio Salvador wrote: Personally I don't like bazaar due performance problem. It's really slow for big projects (it wouldn't be a big problem since GRUB is a small one) and it changes its data format too ofthen. Hmm, I thought they have fixed the performance issues already? About the data format, I have no idea. jbailey, do you have any comment? ;) I've used bzr when working on my summer of code project 1.5 years ago and didn't have any issues with performance. And this was before they did all the performance improvements. Maybe with big source trees like Linux it's still too slow, but for GRUB this is really no problem. I'm not talking about working locally (looks like this is what you've done) but pulling and pushing changes remotely. The changes in data format shouldn't really be any problem in practice, because newer versions can still read the older disk format and the network protocol doesn't change most of the time. I think it's. If you want to gain their performance improvements you _need_ to upgrade. So _all_ people involved will need to have the need version installed too. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Fri, 2008-01-04 at 13:32 +0100, Robert Millan wrote: On Thu, Jan 03, 2008 at 11:23:01AM -0500, Pavel Roskin wrote: Why? Does the firmware impose this restriction, or is it GRUB itself that gets confused? I wish I knew it. 0x7000 is not OK, 0x8000 is OK. Less granularity makes no sense since the value is aligned at the 0x1000 boundary. AFAICT, it can only happen in three ways: 1- The firmware doesn't like GRUB image, and aborts with bogus errors before transferring control to GRUB. You can easily tell this appart by checking for early Welcome to GRUB message. I'm quite sure now that it's the case. That's how it looks on the surface, I just was extra cautious before I had a chance to learn more about OpenFirmware and the GRUB code. Not only there is no Welcome to GRUB message, but the screen is not erased and remains black on white. CLAIM failed is followed by the OpenFirmware prompt. There are no messages that the execution was interrupted, which would appear in other failure cases. I tried to convert grub-mkimage output to the binary format, and found that objcopy doesn't like it. In fact, the image doesn't even survive simple objcopy intact. objcopy grubof.modules grubof.modules1 produces a file 208 bytes long. Moreover, objdump -h grubof.modules doesn't show any sections at all, whereas objdump -p grubof.modules shows the segments. It seems to me that grub-mkimage produces something that looks like and ELF file and the first glance, but is not a valid ELF file. I can reproduce this problem with linuxbios images on i386. We just cannot expect OpenFirmware to process invalid ELF files. It can be looking for the section headers and finding non-zero data is the gap is not wide enough. It can be just anything. A quick look into util/elf/grub-mkimage.c finds Don't bother preserving the section headers. I don't even know if the problem is specifically with the section headers or with something else. Perhaps util/elf/grub-mkimage.c should be rewritten as a linker script, or maybe it should use the BFD library that comes with binutils. I'm optimistic about the linker script, since all we need is essentially linking. There is a possibility that grub_errno remains set to some error. Well, that's easy to tell appart with some printfs. What I see is the last invocation of grub_ofdisk_open() has grub_errno set to 13 (EACCESS) throughout the code. It's never unset by any successful operations. I think some filesystem module may be resetting grub_errno to 0. It's strange that I don't even see EACCESS in the code. A quote from the glibc manual: These functions do not change `errno' when they succeed; thus, the value of `errno' after a successful call is not necessarily zero, and you should not use `errno' to determine _whether_ a call failed. The proper way to do that is documented for each function. _If_ the call failed, you can examine `errno'. grub_ofdisk_open() is in direct violation of that rule. The execution can reach the fail: label without having failed anywhere, yet the code returns grub_errno unconditionally. That's not to negate your findings, of course. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] split realmode and loader routines out of startup.S
On Fri, Jan 04, 2008 at 06:15:17PM +0100, Jeroen Dekkers wrote: At Tue, 16 Oct 2007 23:09:07 +0200, Robert Millan wrote: This patch splits realmode and loader routines out of startup.S. The idea is that the LinuxBIOS port can be adapted to share more code with the rest of GRUB instead of duplicating it. This is quite critical stuff, so even if the change seems trivial I'd suggest being careful, since I don't trust myself too much. Of course, I've tested that it can still boot Linux and Multiboot (on qemu only). Perhaps testing on real hardware would be appropiate (but I don't have this handy atm). SNIP * kern/i386/pc/startup.S (protstack): Moved to ... * kern/i386/realmode.S (protstack): ... here. * kern/i386/pc/startup.S (gdt): Moved to ... * kern/i386/realmode.S (gdt): ... here. * kern/i386/pc/startup.S (prot_to_real): Moved to ... * kern/i386/realmode.S (prot_to_real): ... here. * kern/i386/pc/startup.S: Include `kern/i386/loader.S' and `kern/i386/realmode.S'. Why did you move prot_to_real to realmode.S, but not real_to_prot? That seems a bit strange to me... Because on i386-pc, GRUB wants to do both things, but on i386-linuxbios, you start in protected mode and only want to switch once to real mode when booting Linux. There's no way back AFAICT. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] memtest86+ fix
On Thursday 03 January 2008 02:06, Robert Millan wrote: On Thu, Jan 03, 2008 at 12:46:15AM +0100, Yoshinori K. Okuji wrote: On Wednesday 02 January 2008 18:05, Robert Millan wrote: This fixes boot for memtest86+ (and actually, Linux zImages since they were all affected). The problem was that the first code in grub_linux_boot_zimage copied the payload from 0x10 to 0x1. Since GRUB starts at 0x8200 and is typicaly more than 8 kiB in size, it'll most likely overwrite part of it. A bit of reestructuring was necessary to allow grub_dl_unload_all() to happen unconditionally as first step, since the information on whether this is a big linux was not promptly available. Comments? It is okay, except for grub_linux_big... I cannot figure out what it wants to say. As you want to make it global, please choose a more expressive name, such as grub_big_linux_loaded. How about grub_linux_big_loaded, for consistency with the other vars in machine/kernel.h that also start with grub_linux_ ? big_loaded sounds horrible to me. How about grub_linux_big_image_loaded? Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: spam in commit-grub
On Thursday 03 January 2008 02:08, Robert Millan wrote: On Thu, Jan 03, 2008 at 01:55:37AM +0100, Robert Millan wrote: I wouldn't like to run the risk of missing legitimate mail, specially in this case that blocking spam is just a matter of restricting who can post to commit-grub (like it happens on this list, which thankfuly is completely spam-free). Ah, the irony, I think I remember myself complaining that this list didn't allow post to non-subscribers :-) But actually the list is limited to subscribers. So if you get a spam, probably the from address was identical to a subscriber. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] memtest86+ fix
On Sat, 2008-01-05 at 02:09 +0100, Yoshinori K. Okuji wrote: big_loaded sounds horrible to me. How about grub_linux_big_image_loaded? big image is normally abbreviated as bzimage, as opposed to zimage, so I would suggest something of this kind: grub_is_bzimage grub_linux_is_bzimage grub_bzimage_loaded grub_linux_bzimage_loaded -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: variable hooks global variables
On Thursday 03 January 2008 16:05, Robert Millan wrote:
On Thu, Jan 03, 2008 at 04:03:11PM +0100, Robert Millan wrote:
When you set a variable hook (grub_register_variable_hook), this hook
isn't preserved after someone (e.g. configfile command) opens a new
context (grub_env_context_open), unless the variable has been set as
global (grub_env_export).
Is this what we want?
The only current user of variable hooks is root variable, and that hook
contains a sanity check that seems to be more suitable for global scope.
The color-related variables for which I wanted to add hooks would also
like to keep their hooks across contexts.
One option is to export these variables, or to modify
grub_env_context_open() to preserve hooks as well as exported variables.
I'm more inclined for the latter.
Comments?
Erm, ignore the part about global variables. Exporting them doesn't help:
for (var = context-prev-vars[i]; var; var = var-next)
{
if (var-type == GRUB_ENV_VAR_GLOBAL)
if (grub_env_set (var-name, var-value) != GRUB_ERR_NONE)
{
grub_env_context_close ();
return grub_errno;
}
}
So, we just preserve hooks ?
Global variables should preserve hooks. This is a bug. Local ones should not.
If you want to have a variable to be inherited, you must make it global.
Okuji
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot.texi
On Thursday 03 January 2008 14:59, Robert Millan wrote:
I'd like to copy grub/docs/multiboot.texi into grub2 CVS, and start
providing it as part of the docs.
The copyright holders are:
Copyright @copyright{} 1995,96 Bryan Ford baford@@cs.utah.edu
Copyright @copyright{} 1995,96 Erich Stefan Boleyn erich@@uruk.org
Copyright @copyright{} 1999,2000,2001,2002,2005,2006 Free Software
Foundation, Inc.
Is that fine?
After that, we might want to create multiboot2.texi as a draft based on
this one.
I am still wondering if it is a good idea to bundle the spec with GRUB. For
me, they are different projects, so I might prefer to make a separate
distribution.
Okuji
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Thursday 03 January 2008 16:28, Pavel Roskin wrote: Linux style description. The first line is the synopsis. If it doesn't fit 72 characters, the patch is a candidate for splitting. Then an empty line. Then a more detailed description of the patch, including the motivation behind the changes. The list of the affected files can be generated by the version control system. Looks good. But I guess you'll have to convince Marco and Okuji about this :-) Sure, it's in my TODO list :) I do not think automatically generated logs can be as precise as being made by human. Anyway, there is no reason that you shouldn't write a detailed description in ChangeLog. Indeed, I myself sometimes do that, when I make a big change or something hard to understand. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Transparent decompression with file system filter
On Thursday 03 January 2008 16:53, Vesa Jääskeläinen wrote: Bean wrote: On Jan 3, 2008 7:19 AM, Yoshinori K. Okuji [EMAIL PROTECTED] wrote: Please wait a minute. Personally, I don't want grub_file_open to decompress a content automatically. The name should stand for what it does. That was why I named grub_file_open and grub_gzfile_open like this. This was really one of what I didn't like in GRUB Legacy. If you want to have a function to open any kind of compressed file, please add something else (e.g. grub_compressed_file_open). ok, i keep grub_file_open as it is, and add a new function grub_zfile_open to handle compressed file. i also expand the list of commands that use auto decompression: For me zfile doesn't say a thing. Where as name proposed by Okuji is clear to me instantly. Our current compilers can handle long symbol names fine, so why not use them if they make things clearer :) ? Agreed. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-pc: installation failure under linux + udev
On Friday 04 January 2008 00:54, Robert Millan wrote: On Thu, Jan 03, 2008 at 11:14:23PM +0100, Pascal A. Dupuis wrote: Hello, this is a copy of debian bug 450709 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450709) at debian maintainer's (Robert Millan rmh at aybabtu dot com) request: Thanks Pascal. But ... util/biosdisk.c has another issue with detecting udev. The routine has_devfs searchs for /dev/.devfsd, which cames from deprecated devfs. Enclosed is a synthetic patch, I compiled and ran it fine on my machine. Could you check ? The off-by-5 bug is already fixed in CVS. As for the devfs part, I think I figured out what you're doing. You setup udev to emulate devfs-style devices, right? I think the right fix for this is not to check for /dev/.udev, but rather just probe for devfs-style devices unconditionally. As it happens there are other ways in which one could have this layout, including other /dev implementations such as userdevfs. What does everyone else think? As long as it works fine, no problem. :) Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: opening new context (was: [PATCH] allow user-configurable menucolor)
On Friday 04 January 2008 09:02, Robert Millan wrote: On Thu, Jan 03, 2008 at 06:04:59PM +0200, Vesa Jääskeläinen wrote: About new context: Shouldn't new context have clone of it's parent contexts settings? I wouldn't want to change that without having some input from whoever designed (or understands) grub_env_export(). There's probably a reason for it, although I can't see it. It is analogous to bash. If you invoke another bash from bash, that won't inherit variables, unless they are exported. Besides that, I think it is a good thing that some kind of clean room or sandbox is guaranteed. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] skip `.' and `..' directories in TAB completion
On Friday 04 January 2008 13:14, Robert Millan wrote: This patch skips . and .. directories in tab completion. They're basicaly useless to the user, and this mimics bash completion behaviour. Okay for me. Thanks, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Friday 04 January 2008 21:37, Robert Millan wrote: A quick look into util/elf/grub-mkimage.c finds Don't bother preserving the section headers. I don't even know if the problem is specifically with the section headers or with something else. Perhaps util/elf/grub-mkimage.c should be rewritten as a linker script, or maybe it should use the BFD library that comes with binutils. I'm optimistic about the linker script, since all we need is essentially linking. There's another [1] outstanding problem with elf/grub-mkimage.c: http://lists.gnu.org/archive/html/grub-devel/2007-10/msg00056.html I think what you propose is a good idea. It sounds odd that we have to reimplement ELF handling when another GNU project already has. But I don't know how the GRUB maintainers think about it. [1] or, perhaps, it's the same problem? I object to using a linker, since it is more odd that the user must install development tools to just install GRUB. About BFD, the old discussion was that it made the binary size bloated, thus didn't fit into a small disk or initrd or whatever, so it was not convenient for installers. I don't know if the same discussion can apply nowadays, since most people install operating systems by CD or DVD, memory size is plenty, etc. Especially if this is only for OpenFirmware platforms, I don't believe that anybody cares. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Sat, 2008-01-05 at 02:27 +0100, Yoshinori K. Okuji wrote: On Thursday 03 January 2008 16:28, Pavel Roskin wrote: Linux style description. The first line is the synopsis. If it doesn't fit 72 characters, the patch is a candidate for splitting. Then an empty line. Then a more detailed description of the patch, including the motivation behind the changes. The list of the affected files can be generated by the version control system. Looks good. But I guess you'll have to convince Marco and Okuji about this :-) Sure, it's in my TODO list :) I do not think automatically generated logs can be as precise as being made by human. Anyway, there is no reason that you shouldn't write a detailed description in ChangeLog. Indeed, I myself sometimes do that, when I make a big change or something hard to understand. We are talking about a changeset from 2007-02-21 (the earliest of them), where the ChangeLog entry has the usual calculate this and rename this to that. It took me hours of experiments to figure out that the intention was to load the core image and the modules much lower in the memory. Sure, it looks trivial when explained. And by the way, a trivial change that doesn't modify anything as fundamental as memory layout could be described in very similar terms. There is no way to see how profound changes are and whether they are relevant to the observed problems. Detailed descriptions may be useful in many cases, but in my opinion, they should be secondary to high level descriptions. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Fri, 2008-01-04 at 21:37 +0100, Robert Millan wrote: If you want to confirm that it's grub-mkimage's fault, you can try booting kernel.elf directly. In theory it should give you a rescue prompt. That's what it does. And that's what we have been discussing closer to the bottom :-) In fact, the image doesn't even survive simple objcopy intact. objcopy grubof.modules grubof.modules1 produces a file 208 bytes long. What is grubof.modules ? I never heard of it. That's the suggested name for the grub-mkimage output on PowerPC, according to http://grub.enbug.org/TestingOnPowerPC Yes, it's long and misleading. Maybe it should be called grub.elf or something. I'm usually good at inventing new names, but I have no good ideas this time :-) Wait, that would be EACCES in Linux errno codes. In GRUB, grub_errno 13 means GRUB_ERR_UNKNOWN_DEVICE (at the time of writing; there isn't a stable ABI for this afaik). Thanks, that explains something! If grub_errno was set you should've seen an error message somewhere. It seems there's something wrong in our error handling. :-/ I agree. I would really check the GRUB_IEEE1275_FLAG_NO_PARTITION_0 issue. It was just a guess, but it smells really badly :-) I'll have a look. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Transparent decompression with file system filter
On Jan 5, 2008 9:29 AM, Yoshinori K. Okuji [EMAIL PROTECTED] wrote: On Thursday 03 January 2008 16:53, Vesa Jääskeläinen wrote: Bean wrote: On Jan 3, 2008 7:19 AM, Yoshinori K. Okuji [EMAIL PROTECTED] wrote: Please wait a minute. Personally, I don't want grub_file_open to decompress a content automatically. The name should stand for what it does. That was why I named grub_file_open and grub_gzfile_open like this. This was really one of what I didn't like in GRUB Legacy. If you want to have a function to open any kind of compressed file, please add something else (e.g. grub_compressed_file_open). ok, i keep grub_file_open as it is, and add a new function grub_zfile_open to handle compressed file. i also expand the list of commands that use auto decompression: For me zfile doesn't say a thing. Where as name proposed by Okuji is clear to me instantly. Our current compilers can handle long symbol names fine, so why not use them if they make things clearer :) ? Agreed. I'm thinking that compressed might not be the right word, as filter doesn't limit to decompression, it can support decryption or format conversion as well. I guess the name grub_file_open_ex may be better. I also add a flag to the function, if flag!=0, filters are used, and if flag=0, grub_file_open_ex is just like grub_file_open. I also change the name fshook to filehook, as these filters only affect file based operation. The controlling variable is now filehook. When filehook=0, filters are disabled globally. -- Bean grub2-filehook.diff Description: Binary data ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-fstest: debug tool for filesystem driver
On Jan 4, 2008 8:08 PM, Bean [EMAIL PROTECTED] wrote: On Jan 4, 2008 7:53 PM, Robert Millan [EMAIL PROTECTED] wrote: On Thu, Jan 03, 2008 at 01:11:32AM +0800, Bean wrote: blst FILE display the blocklist of FILE in the image file Is this `blst' analogous to the `blocklist' command we already have? In that case, I'd suggest giving it the same name. yep, it's the same. Change command names: dump - hex blst - blocklist Also replace grub_file_open with grub_file_open_ex from my latest filehook patch. -- Bean grub2-fstest2.diff Description: Binary data ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
