Re: [PATCH] Corrections to affs and sfs
Hello, Robert Millan pisze: Index: fs/sfs.c === --- fs/sfs.c(revision 1919) +++ fs/sfs.c(working copy) @@ -172,7 +172,8 @@ return grub_errno; } - for (i = 0; i grub_be_to_cpu16 (tree-nodes); i++) + grub_uint16_t nodescount = grub_be_to_cpu16(tree-nodes); + for (i = nodescount - 1; i = 0; i--) nodescount is only used once; why adding a variable? No particular reason. Feel free to correct it :) Best regards, Krzysztof ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: rename grub to grub-legacy ?
On Thu, Oct 09, 2008 at 11:36:51AM -0400, Pavel Roskin wrote: On Thu, 2008-10-09 at 11:53 +0200, Felix Zielcke wrote: Am Dienstag, den 07.10.2008, 21:24 +0200 schrieb Yoshinori K. Okuji: I have no objection. Sorry for a slow response. So if I understand it right then `svn mv svn+ssh://svn.sv.gnu.org/grub/trunk/grub svn+ssh://svn.sv.gnu.org/grub/trunk/grub-legacy' should do it, inclusive saving the history? I just better ask before trying it out :) Preserving history is not perfect. I believe it's impossible to refer to the old revisions by the new names in diff, so one would need to use old paths for the pre-move revisions. Anyway, svn mv is the Subversion way of doing things. If we are certain that we want to move the repository, it's better to do it early. It's also better to do it when there are no unmerged branches. I believe Okuji wanted to use a different naming scheme, that would put grub2 or grub-legacy above trunk. You may want to check it to avoid moving things twice. All the above notwithstanding, I'm still skeptical about the whole moving idea based on my experience with other projects. Repositories are for developers and should be used in the way that minimizes troubles for developers rather than reduces the entry barrier for newbies. If GRUB2 is moved in any way, I'm not sure I'll be able to keep the git mirror at repo.or.cz up to date. It doesn't seem that git-svn can deal with it. I'm going to try to keep is running, but I cannot promise it. Perhaps we should just rename the tarball in next release. The point was to send a message down to distributors, not to create an inconvenience for us. Okuji, what do you think? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] (ata.mod) avoid passing grub_errno to upper layer
Okay, I think I got what you mean. So how about this one?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
2008-11-29 Robert Millan [EMAIL PROTECTED]
* disk/ata.c (grub_ata_pciinit): Handle errors rised by
grub_ata_device_initialize() calls.
Index: disk/ata.c
===
--- disk/ata.c (revision 1929)
+++ disk/ata.c (working copy)
@@ -542,6 +542,16 @@ grub_ata_pciinit (int bus, int device, i
{
grub_ata_device_initialize (controller * 2 + i, 0, rega, regb);
grub_ata_device_initialize (controller * 2 + i, 1, rega, regb);
+
+ /* Most errors rised by grub_ata_device_initialize() are harmless.
+ They just indicate this particular drive is not responding, most
+ likely because it doesn't exist. We might want to ignore specific
+ error types here, instead of printing them. */
+ if (grub_errno)
+ {
+ grub_print_error ();
+ grub_errno = GRUB_ERR_NONE;
+ }
}
}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Parallel kernel loading and keystroke capture in GRUB2
Arjan van de Ven wrote, on 2008-11-29 02:06: Vlad wrote: Hi, In a recent demonstration of how to boot Linux in 5 seconds [1], PowerTOP developers did not use GRUB2, even though GRUB2 is a necessary component of any production and consumer Linux system or multi-boot environment. As I see it, the greatest disadvantage of GRUB2 is that it needlessly wastes the time in which it gives the user the chance to stall the boot sequence in order to make changes to the boot settings. Of course, having this option available is a necesity in case the user's hardware requires tweaking the parameters passed to the kernel. However, GRUB2 should be loading the default kernel during this time, instead of deferring this IO-bound task to after the timeout has elapsed. we used grub 1. Since popular Linux distros typically display the GRUB2 intro message for 30 seconds, I'm not aware of mainstream distributions using grub2 yet. Also, I'm not aware of any distro using 30 seconds as timeout, the longest I've seen is 5 seconds. Debian GNU/Linux offers grub2 as an option on installation. Arthur. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] (ata.mod) avoid passing grub_errno to upper layer
Committed (after repeating the same block for both calls, as Vesa suggested
on IRC).
On Sat, Nov 29, 2008 at 07:37:46PM +0100, Robert Millan wrote:
Okay, I think I got what you mean. So how about this one?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
2008-11-29 Robert Millan [EMAIL PROTECTED]
* disk/ata.c (grub_ata_pciinit): Handle errors rised by
grub_ata_device_initialize() calls.
Index: disk/ata.c
===
--- disk/ata.c(revision 1929)
+++ disk/ata.c(working copy)
@@ -542,6 +542,16 @@ grub_ata_pciinit (int bus, int device, i
{
grub_ata_device_initialize (controller * 2 + i, 0, rega, regb);
grub_ata_device_initialize (controller * 2 + i, 1, rega, regb);
+
+ /* Most errors rised by grub_ata_device_initialize() are harmless.
+ They just indicate this particular drive is not responding, most
+ likely because it doesn't exist. We might want to ignore specific
+ error types here, instead of printing them. */
+ if (grub_errno)
+ {
+ grub_print_error ();
+ grub_errno = GRUB_ERR_NONE;
+ }
}
}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multi-terminal support (Re: [PATCH] terminal split)
Robert Millan wrote: On Tue, Nov 25, 2008 at 10:23:52PM +0100, Yoshinori K. Okuji wrote: I've been thinking... what if we make this generic? I.e. with an event loop, then terminals can register their poll functions to it, and write their stuff to a shared resource the rest of GRUB can read from. For inputs, this is trivial for me. But, for outputs, not simple. For example, although we don't support yet in GRUB 2, if we have a dumb terminal, the menu interface must be very different from others. Aside from the problem with output ones, what to you think of the event loop idea? It can be useful exploit the parellelism in hardware initialisations. Currently GRUB can do silly things like: - wait for keyboard controller in grub_keyboard_controller_read() and in grub_keyboard_controller_write() - move on - wait for ATA disk in grub_atapi_read() - move on - wait for _user_ to stare at the menu and pick an option - move on which could be avoided this way (instead of waiting, each function would register a hook that will be repeatedly run untill it returns non-zero). Well... I think better road would be co-operative multitasking. While waiting for hardware to respond you could give time to other tasks to handle their stuff. This would also make easier to write such tasks as you do not have to think about complex event system. System you propose can get quite complex to understand and maintain. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
I'm a newb, looking for guidance
Hi, I'm very interested in helping out with the grub project, but I don't know where to begin! I've been interested in the project for a long time, but I try to respect people's time and I don't like to ask stupid questions until I've searched hard for the answers by myself. I've tried very hard to find good documentation for GRUB, but, erm..all of the decent tutorials out there are incomplete at best, and many of them make too many assumptions to be very helpful. I've read many tutorials but it seems like each one conflicts with the others. First of all, I'm having trouble even understanding the grub architecture, and most of that is because I am constantly seeing conflicting information all over the internet due to the common fact that many people are ambiguous with which branch of grub they are referring to. Also, there seems to be a plague of broken and outdated links. In general, though, I've found that grub is extremely underdocumented; but of the reading material which I have found to be at all helpful, there is a MAJOR tendency to overcomplicate things. I have a background in C and x86 assembly programming, and have had my fair share of device driving programming. I enjoy helping others track down bugs in their code, and I love writing idiot-proof tutorials (being the idiot that I am). I'm not afraid to sit down and read thousands of lines of code if that's what it takes to be up to date with the project. I just want to make sure I'm not headed in the wrong direction or anything. I remember reading a LONG time ago that the ETA for GRUB-2.0 was November 2008, and so I expected to start seeing a lot more tutorials devoted to helping people prepare for it, but this hasn't happened as quickly as I'd hoped. So I figured I would try to delve into the project and see what's REALLY going on. I've only been using linux for a little over a year, and before that was a windows programmer (yes, I'm ashamed of my past), so I know I won't be much help as far as programming anything useful anytime soon. I can, however, offer to seek and hunt down typos or inconsistencies in the code comments, that is unless the grub team is against that idea. I think proper documentation is the key to any project's long term survival, and I take comments seriously and expect them to be unambiguous and at the same time not superfluous. So then, there's a grub forest of source code files, and I'm ready to walk in. I'll probably get lost in the woods sometime, so I'd appreciate it if anyone know of a trail I could follow. Thanks! -- Jay Sullivan ([EMAIL PROTECTED]) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: G5 powerpc64 undefined reference to `grub_machine_mmap_iterate'
all fixed now thanks. On Sat, Nov 29, 2008 at 11:16 AM, peter cros [EMAIL PROTECTED] wrote: Yes, thanks, I already ran the patch and checked the files, but still get the error. I will recheck, I may be doing something wrong here, but no compile problems before 1924 . I dont know if the machine could affect this, it is Apple powermac G5. On Sat, Nov 29, 2008 at 12:57 AM, Manoel Rebelo Abranches [EMAIL PROTECTED] wrote: I have already sent a patch to correct this. look at the email with subject [PATCH] Compilation PowerPC64. It should work for you. On Sat, 2008-11-29 at 00:12 +1100, peter cros wrote: After Revision 1924 Harmonize ieee1275's grub_available_iterate() with the generic grub_machine_mmap_iterate() Attempting to make Rev 1928, configuration ieee1275 on G5 powerpc64 I am stuck with this error: kernel_elf-kern_ieee1275_init.o: In function `grub_claim_heap': /home/pxw/src/grub2/build/../kern/ieee1275/init.c:182: undefined reference to `grub_machine_mmap_iterate' kernel_elf-symlist.o:(.data+0x38c): undefined reference to `grub_machine_mmap_iterate' collect2: ld returned 1 exit status make: *** [kernel.elf] Error 1 I cant find it, would appreciate help. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Best Regards, Manoel Abranches [EMAIL PROTECTED] IBM Linux Technology Center Brazil ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel Peter Cros ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
