Re: [PATCH] Split of the normal mode
Move from todo on wiki is done except UltraSparc. David Miller: these todos seem to be very outdated by your work. If some of them or new tasks are applicable could you add them to task tracker? # Install on disk # Grub emu # Boot something # Write a grub-install script to install grub and configure OF variables properly. This will be different from PPC because Sparc has openpromfs and is missing sysfs "devspec" links into the device tree. phcoder wrote: Once I finish (not a lot remaining) I'll just put a notice in the head that this page is preserved for historical purposes only and indications to use savannah Yoshinori K. Okuji wrote: On Monday 30 March 2009 05:35:08 phcoder wrote: I moved todo to the svannah task track. 3 pieces aren't moved yet -PPC / Ultrasparc -Command list -Feature requests by users Isn't it better to remove the tasks which you moved to Savannah from the wiki? Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split of the normal mode
From: phcoder Date: Wed, 01 Apr 2009 09:43:01 +0200 > Move from todo on wiki is done except UltraSparc. > David Miller: these todos seem to be very outdated by your work. If some of > them or new tasks are applicable could you add them to task tracker? > # Install on disk > # Grub emu > # Boot something > # Write a grub-install script to install grub and configure OF variables > properly. This will be different from PPC because Sparc has openpromfs and is > missing sysfs "devspec" links into the device tree. This should all just be deleted. It's either going to be done by my patches or is irrelevant. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: grub: Fix sparc64 setjmp implementation, update grub_setjmp() attributes.
From: "Yoshinori K. Okuji" Date: Sat, 28 Mar 2009 23:34:25 +0900 > On Saturday 28 March 2009 22:39:48 Robert Millan wrote: > > Unless there's someone else in the list who is knowledgeable about sparc > > assembly and is going to review this part of David's patch, I'm going to > > assume it's fine and check it in. > > > > This also goes for future patches sent by David. So if you will speak, > > do it now :-) > > I know a bit, but not that much. So I vote for that we just trust him. ;) Ping? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split of the normal mode
David Miller wrote: From: phcoder Date: Wed, 01 Apr 2009 09:43:01 +0200 Move from todo on wiki is done except UltraSparc. David Miller: these todos seem to be very outdated by your work. If some of them or new tasks are applicable could you add them to task tracker? # Install on disk # Grub emu # Boot something # Write a grub-install script to install grub and configure OF variables properly. This will be different from PPC because Sparc has openpromfs and is missing sysfs "devspec" links into the device tree. This should all just be deleted. It's either going to be done by my patches or is irrelevant. ok, thanks. Now everything is in savannah task tracker. As for command list I added important missing commands to task tracker and skipped not-so-useful ones. As there is some subjectivity involved if you don't agree with my choice just say it. Similar situation is with user's feature requests. I moved the ones that are out of scope of grub2 or already done to "Invalid requests" section. As for other I see none which are priority right now. If you disagree again just say. Also I'm currently adding patches which are pending for more then one week -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot on EFI
On Sat, Mar 28, 2009 at 11:31:14PM +0900, Yoshinori K. Okuji wrote: > On Saturday 28 March 2009 22:13:06 Robert Millan wrote: > > Do we need the memory map to be sorted? AFAIK loadees can cope with > > unsorted maps fine; is there an exception? > > As I wrote in the draft, a boot loader should sort the memory map. An OS > image > must deal with an unsorted memory map, because the wording is "should", but > it is still user-friendly (especially for debugging). You mean the multiboot 2 draft? Since this change is backward-compatible, is there any reason we want this in multiboot 2 but not in multiboot 1? I don't like that the two diverge so much, it makes the implementation so much harder to maintain. Right now the multiboot 2 loader is a complete bitrot. Can we merge this and similar backward-compatible changes into multiboot 1? -- 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]: grub: Fix sparc64 setjmp implementation, update grub_setjmp() attributes.
On Wed, Apr 01, 2009 at 01:17:40AM -0700, David Miller wrote: > From: "Yoshinori K. Okuji" > Date: Sat, 28 Mar 2009 23:34:25 +0900 > > > On Saturday 28 March 2009 22:39:48 Robert Millan wrote: > > > Unless there's someone else in the list who is knowledgeable about sparc > > > assembly and is going to review this part of David's patch, I'm going to > > > assume it's fine and check it in. > > > > > > This also goes for future patches sent by David. So if you will speak, > > > do it now :-) > > > > I know a bit, but not that much. So I vote for that we just trust him. ;) > > Ping? Committed. -- 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] GRUB_GFXMODE_LINUX user variable
On Sun, Mar 29, 2009 at 05:39:36PM +0900, Yoshinori K. Okuji wrote: > On Sunday 29 March 2009 11:31:29 Robert Millan wrote: > > This patch adds GRUB_GFXMODE_LINUX user variable to make it easy for > > users to set graphical mode before booting Linux. > > Is this really Linux-specific? It look somehow coincidental to me that this > is > used only for Linux. If other operating systems, such as FreeBSD, support > that way of switching a video mode, I think you would want to reuse the same > variable. Agreed. Also, perhaps we should define an env variable like gfxmode, so that loaders can switch mode themselves and "terminal_output gfxterm" doesn't have to be used. I like the terms "payload" and "loadee" because they don't imply what we're loading is a kernel (Linux) or a standalone OS (invaders/memtest86). How about using "gfxmode_payload=WIDTHxHEIGHT[xDEPTH]" ? -- 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] Split of the normal mode
On Sun, Mar 29, 2009 at 07:09:56PM +0900, Yoshinori K. Okuji wrote: > > Indeed. I don't understand this tendency about splitting modules at all. What > is the motivation behind? What is the real benefit for the user? > > From my point of view, it is wrong to force the user to manually load > modules, > generally. This includes writing "insmod" in config files. Look at Linux. It > is quite rare to execute insmod or modprobe directly. Most of the time, > modules are loaded on demand. This is the user-friendliness. I agree with your point. It should be noted, though, that in some of these situations grub-mkconfig compensates that by generating "insmod xxx" statements on-demand (a good example would be that "insmod lvm" can be generated by prepare_grub_to_access_device). > FYI, I am planning to make a full review of recent changes (i.e. all changes > made after I stopped reviewing every patch), and trash/revert/rewrite/blame > everything I don't like. Changes made for no good reason must be all > reverted. > > In brief, I take back the leadership of this project for general directions. > For some subsystems (e.g. the coreboot support), I continue leaving the > responsibility to those who know better or are more active. Once the current > code is reviewed and fixed (at some degree), I will make a new release. > > Any objection? GRUB is in dire need of an active project lead. I'm happy to see what you plan to take back on that role. Over the last few months, I tried to cover up for some of the work you and Marco weren't doing, like processing the patches nobody wanted to look at, or requesting copyright assignments. TBH, it wasn't a pleasant task, and if you'll be doing it from now on, it's a relief for me. As for reverting changes, I acknowledge you have the authority to do that, but it would be very harmful to the project if all sort of things started being reverted with no proper discussion. When I say harmful, I mean that some people might end up sticking with their own private trees, which later can't easily be merged. It's very important to build consensus on such things. So my suggestion is that you bring up discussion on which things you plan to revert. If we can't reach consensus, you have the authority to impose your own view, but please try to find consensus, and be open to arguments that might convince your POV. To summarize, I approve of your decision, but I'd be very disappointed if all this just happens so you can revert a bunch of stuff and inmediately afterwards we're left with no active maintainer again. -- 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] build 32-bit Linux loader as `linux', rename legacy loader to `linux16'
On Mon, Mar 30, 2009 at 05:51:22PM -0400, Pavel Roskin wrote: > On Tue, 2009-03-31 at 01:06 +0900, Yoshinori K. Okuji wrote: > > On Monday 30 March 2009 23:35:52 phcoder wrote: > > > I confirm. I suppose that this check and message is bypassed with 32-bit > > > loading mode. IMO grub2 should provide an equivlent of this check. We > > > already have cpuid code. Does anyone know how to determine if kernel is > > > i386 or amd64? > > > > I don't know any reliable way. Some candidates: > > > > - The ramdisk max value. On 32-bit, initrd may not be loaded onto over 2GB. > > This is hard to change in Linux, so we can expect that this will not > > change. > > If we are circumventing the standard Linux bootloader, perhaps we should > communicate this to the Linux developers. This is not circumvention. We're using a 32-bit interface that's part of their boot protocol specification (i.e. they promised not to break it). The only caveat is that so far it's only used on EFI and on coreboot, it hasn't been so widespread, and therefore not so widely tested yet. -- 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] build 32-bit Linux loader as `linux', rename legacy loader to `linux16'
On Tue, Mar 31, 2009 at 01:06:25AM +0900, Yoshinori K. Okuji wrote: > I don't know any reliable way. Some candidates: > > - The ramdisk max value. On 32-bit, initrd may not be loaded onto over 2GB. > This is hard to change in Linux, so we can expect that this will not change. > On 64-bit, currently, the max is 4GB-1. It is likely that this value will not > change, but who knows. This could be possible, but doesn't sound very reliable. > - The long mode panic message. This exists only for x86_64. But the message > might change some day. Actually, it seems to have changed recently. Doesn't seem too reliable either. > - Otherwise, we could probe some opcodes and see if 64-bit opcodes are used. > This would be error-prone. Same here :-( However, this is not as large a problem as it seems. Most users install GRUB to disk through their distribution, which already provides the right Linux builds in /boot. It could be a problem with removable media, but: - It's easy to solve this when you have a "cpuid" command and know what each of the files you put in the CD is. This also allows for a more user-friendly error message than a Linux panic. - GRUB is rarely used there anyway (most GNU/Linux distros opt for isolinux) -- 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: Move loader.c out of the kernel
On Tuesday 31 March 2009 17:56:24 phcoder wrote: > With a new swing in normal.mod splitting I think we should reconsider > this patch. It's useless to keep loader.c in kernel without boot > command. IMO it should be moved either to a perate boot.mod (my > preference) or to minicmd.mod (not a good option IMO) As I said, rescue mode is not quite useful without any loader. So the loader interface should be built into the kernel, and the boot command should be as well naturally. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Raid 5 on raw disk install is broken.
On Tuesday 31 March 2009 05:04:19 Centurion Computer Technology (2005) Ltd wrote: > Hi, > > I have a raid array named /dev/md/d0 > > The comand > > grub-setup -r "(md0,1)" "(md0)" fails with: > grub-setup: error: Can't open /dev/md0: No such file or directory. > > I have traced this down to lines 68 - 70 in util/raid.c a copy of the > offending lines is: > > devname = xmalloc (strlen (name) + 6); > strcpy (devname, "/dev/"); > strcpy (devname+5, name); > > The problem is that it appears to sake the grub device id "md0" and > simply append it to the string "/dev/" to get /dev/md0. This will break > any installation of grub on mdraid whole disk sets. > > Can I suggest a fix might be a similar method used by util/hostdisk > function opendisk: > (Line 311):strcpy (dev, map[disk->id].device); Would you like to send a patch? > Also, can someone point me to the resources I need so I can build the > debian package out of the svn tree? Sorry, I don't know, as I am not a Debian user. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot on EFI
On Wednesday 01 April 2009 21:57:55 Robert Millan wrote: > On Sat, Mar 28, 2009 at 11:31:14PM +0900, Yoshinori K. Okuji wrote: > > On Saturday 28 March 2009 22:13:06 Robert Millan wrote: > > > Do we need the memory map to be sorted? AFAIK loadees can cope with > > > unsorted maps fine; is there an exception? > > > > As I wrote in the draft, a boot loader should sort the memory map. An OS > > image must deal with an unsorted memory map, because the wording is > > "should", but it is still user-friendly (especially for debugging). > > You mean the multiboot 2 draft? Since this change is backward-compatible, > is there any reason we want this in multiboot 2 but not in multiboot 1? No. > I don't like that the two diverge so much, it makes the implementation so > much harder to maintain. Right now the multiboot 2 loader is a complete > bitrot. > > Can we merge this and similar backward-compatible changes into multiboot 1? I agree. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: grub: Fix sparc64 setjmp implementation, update grub_setjmp() attributes.
On Wednesday 01 April 2009 22:01:11 Robert Millan wrote: > On Wed, Apr 01, 2009 at 01:17:40AM -0700, David Miller wrote: > > From: "Yoshinori K. Okuji" > > Date: Sat, 28 Mar 2009 23:34:25 +0900 > > > > > On Saturday 28 March 2009 22:39:48 Robert Millan wrote: > > > > Unless there's someone else in the list who is knowledgeable about > > > > sparc assembly and is going to review this part of David's patch, I'm > > > > going to assume it's fine and check it in. > > > > > > > > This also goes for future patches sent by David. So if you will > > > > speak, do it now :-) > > > > > > I know a bit, but not that much. So I vote for that we just trust him. > > > ;) > > > > Ping? > > Committed. David, I can give you a permission, if you tell me your account on Savannah. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GRUB_GFXMODE_LINUX user variable
On Wednesday 01 April 2009 22:05:57 Robert Millan wrote: > On Sun, Mar 29, 2009 at 05:39:36PM +0900, Yoshinori K. Okuji wrote: > > On Sunday 29 March 2009 11:31:29 Robert Millan wrote: > > > This patch adds GRUB_GFXMODE_LINUX user variable to make it easy for > > > users to set graphical mode before booting Linux. > > > > Is this really Linux-specific? It look somehow coincidental to me that > > this is used only for Linux. If other operating systems, such as FreeBSD, > > support that way of switching a video mode, I think you would want to > > reuse the same variable. > > Agreed. Also, perhaps we should define an env variable like gfxmode, so > that loaders can switch mode themselves and "terminal_output gfxterm" > doesn't have to be used. Not bad. ;) > I like the terms "payload" and "loadee" because they don't imply what we're > loading is a kernel (Linux) or a standalone OS (invaders/memtest86). How > about using "gfxmode_payload=WIDTHxHEIGHT[xDEPTH]" ? I am more used to Multiboot's terminology, so I prefer "OS Image". Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] build 32-bit Linux loader as `linux', rename legacy loader to `linux16'
On Wed, 2009-04-01 at 15:23 +0200, Robert Millan wrote: > On Mon, Mar 30, 2009 at 05:51:22PM -0400, Pavel Roskin wrote: > > > > If we are circumventing the standard Linux bootloader, perhaps we should > > communicate this to the Linux developers. > > This is not circumvention. We're using a 32-bit interface that's part of their > boot protocol specification (i.e. they promised not to break it). The only > caveat is that so far it's only used on EFI and on coreboot, it hasn't been > so widespread, and therefore not so widely tested yet. I see. It looks like the x86_64 kernel has code for printing strings in 16-bit mode and in 64-bit mode, but not in 32-bit mode, in which we enter the kernel. So no easy fix, unfortunately. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split of the normal mode
On Wednesday 01 April 2009 18:22:46 phcoder wrote: > ok, thanks. Now everything is in savannah task tracker. As for command > list I added important missing commands to task tracker and skipped > not-so-useful ones. As there is some subjectivity involved if you don't > agree with my choice just say it. Similar situation is with user's > feature requests. I moved the ones that are out of scope of grub2 or > already done to "Invalid requests" section. As for other I see none > which are priority right now. If you disagree again just say. Thank you so much. It's now so easy to look. :) Personally, I think "Add more loaders" and "Add more filesystems" should be removed, because they are not tasks but directions. They could be written at somewhere, but I don't think it is appropriate to put them into the "task manager". From my point of view, tasks must be possible to finish. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split of the normal mode
On Wednesday 01 April 2009 22:19:00 Robert Millan wrote: > GRUB is in dire need of an active project lead. I'm happy to see what you > plan to take back on that role. Over the last few months, I tried to cover > up for some of the work you and Marco weren't doing, like processing the > patches nobody wanted to look at, or requesting copyright assignments. > TBH, it wasn't a pleasant task, and if you'll be doing it from now on, it's > a relief for me. Well, I don't like that so much, either. So I appreciate if you can continue to do that. :p > As for reverting changes, I acknowledge you have the authority to do that, > but it would be very harmful to the project if all sort of things started > being reverted with no proper discussion. When I say harmful, I mean that > some people might end up sticking with their own private trees, which later > can't easily be merged. It's very important to build consensus on such > things. > > So my suggestion is that you bring up discussion on which things you plan > to revert. If we can't reach consensus, you have the authority to impose > your own view, but please try to find consensus, and be open to arguments > that might convince your POV. > > To summarize, I approve of your decision, but I'd be very disappointed if > all this just happens so you can revert a bunch of stuff and inmediately > afterwards we're left with no active maintainer again. Thank you for your comment. I fully understand what you mean. I will take care. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Move loader.c out of the kernel
On Wed, Apr 01, 2009 at 10:52:26PM +0900, Yoshinori K. Okuji wrote: > On Tuesday 31 March 2009 17:56:24 phcoder wrote: > > With a new swing in normal.mod splitting I think we should reconsider > > this patch. It's useless to keep loader.c in kernel without boot > > command. IMO it should be moved either to a perate boot.mod (my > > preference) or to minicmd.mod (not a good option IMO) > > As I said, rescue mode is not quite useful without any loader. So the loader > interface should be built into the kernel, and the boot command should be as > well naturally. This presses for more space into core.img, which is highly constrained (specially in weird combinations like raid + lvm or crypto in the future). Why is a loader so important for rescue mode? If the loader would work, it means you can read files, so it should be able to load the rest of modules as well. When user is dumped to rescue mode, usually (at least for reports I dealt with in debian) it means GRUB has a bug or didn't setup itself properly, and the /boot/ directory can't be accessed. A loader wouldn't help in these situations. Also, how do you determine which loaders belong in kernel? There can be many specialized loaders like the linux one. Or we could just put multiboot, but the Multiboot loader is quite complex already, and it still has room for growing. Maybe the answer is to write a very simple Multiboot loader and put that in kernel? -- 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] build 32-bit Linux loader as `linux', rename legacy loader to `linux16'
On Wed, Apr 01, 2009 at 10:04:44AM -0400, Pavel Roskin wrote: > On Wed, 2009-04-01 at 15:23 +0200, Robert Millan wrote: > > On Mon, Mar 30, 2009 at 05:51:22PM -0400, Pavel Roskin wrote: > > > > > > If we are circumventing the standard Linux bootloader, perhaps we should > > > communicate this to the Linux developers. > > > > This is not circumvention. We're using a 32-bit interface that's part of > > their > > boot protocol specification (i.e. they promised not to break it). The only > > caveat is that so far it's only used on EFI and on coreboot, it hasn't been > > so widespread, and therefore not so widely tested yet. > > I see. It looks like the x86_64 kernel has code for printing strings in > 16-bit mode and in 64-bit mode, but not in 32-bit mode, in which we > enter the kernel. So no easy fix, unfortunately. It's possible to find a fix for this from Linux side, but IMHO the best long-term fix would be to make whoever installed Linux _and_ GRUB figure out what GRUB should do. Not too much to ask, since we give them the tools (cpuid command) to do it. -- 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: Move loader.c out of the kernel
On Wednesday 01 April 2009 23:19:32 Robert Millan wrote: > On Wed, Apr 01, 2009 at 10:52:26PM +0900, Yoshinori K. Okuji wrote: > > On Tuesday 31 March 2009 17:56:24 phcoder wrote: > > > With a new swing in normal.mod splitting I think we should reconsider > > > this patch. It's useless to keep loader.c in kernel without boot > > > command. IMO it should be moved either to a perate boot.mod (my > > > preference) or to minicmd.mod (not a good option IMO) > > > > As I said, rescue mode is not quite useful without any loader. So the > > loader interface should be built into the kernel, and the boot command > > should be as well naturally. > > This presses for more space into core.img, which is highly constrained > (specially in weird combinations like raid + lvm or crypto in the future). > > Why is a loader so important for rescue mode? If the loader would work, it > means you can read files, so it should be able to load the rest of modules > as well. If some or all modules are trashed, no. Also, the user might be able to read other partitions. > When user is dumped to rescue mode, usually (at least for reports I dealt > with in debian) it means GRUB has a bug or didn't setup itself properly, > and the /boot/ directory can't be accessed. A loader wouldn't help in > these situations. And, the rescue mode does not help very much in this case. > Also, how do you determine which loaders belong in kernel? There can be > many specialized loaders like the linux one. Or we could just put > multiboot, but the Multiboot loader is quite complex already, and it still > has room for growing. Maybe the answer is to write a very simple Multiboot > loader and put that in kernel? That's up to the user IMO. For example, suppose this kind of scenario: - the user has a dual boot environment, say, GNU/Linux and Windows. - she uses GRUB installed with the GNU/Linux. - she has made something stupid in the GNU/Linux (e.g. rm -rf /). In the case of GRUB Legacy, this is the end. It's just unbootable, because stage 1.5 may not boot anything besides stage2. In the case of GRUB 2, if the user has pre-loaded chainload.mod onto the core.img, she can still boot the Windows. Honestly, I am more interested in making it possible to use GRUB for setting up a very robust environment. For example: - the user installs a main OS and a rescue OS into a single machine. The latter can be very compact (e.g. puppy, grml, etc.). - she installs another boot loader into the partition for the rescue OS. - she pre-loads chainload.mod in core.img. I think the chainloader is the most realistic, because it is the smallest loader, and GRUB does not need to read a filesystem, thus no filesystem driver is required for loading an OS. Every time I maintain a remote system, I feel the necessity of being prepared for disasters (e.g. filesystem crashes). Rescue mode is one of the tools required for this goal. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Move loader.c out of the kernel
This usage case isn't the main target case. If you embed the loader (which tend to be quite big) then you already have an overhead from loader module. Why are you so concerned with overhead of boot.mod? But on the other hand this forces all the people in other cases to have boot code in core.img. I want to add preboot hooks and don't want increment size of kernel. multiboot.mod currently increases the size by around 11KB. And my patch doesn't restrict you from putting loader in core.img in any way Yoshinori K. Okuji wrote: On Wednesday 01 April 2009 23:19:32 Robert Millan wrote: On Wed, Apr 01, 2009 at 10:52:26PM +0900, Yoshinori K. Okuji wrote: On Tuesday 31 March 2009 17:56:24 phcoder wrote: With a new swing in normal.mod splitting I think we should reconsider this patch. It's useless to keep loader.c in kernel without boot command. IMO it should be moved either to a perate boot.mod (my preference) or to minicmd.mod (not a good option IMO) As I said, rescue mode is not quite useful without any loader. So the loader interface should be built into the kernel, and the boot command should be as well naturally. This presses for more space into core.img, which is highly constrained (specially in weird combinations like raid + lvm or crypto in the future). Why is a loader so important for rescue mode? If the loader would work, it means you can read files, so it should be able to load the rest of modules as well. If some or all modules are trashed, no. Also, the user might be able to read other partitions. When user is dumped to rescue mode, usually (at least for reports I dealt with in debian) it means GRUB has a bug or didn't setup itself properly, and the /boot/ directory can't be accessed. A loader wouldn't help in these situations. And, the rescue mode does not help very much in this case. Also, how do you determine which loaders belong in kernel? There can be many specialized loaders like the linux one. Or we could just put multiboot, but the Multiboot loader is quite complex already, and it still has room for growing. Maybe the answer is to write a very simple Multiboot loader and put that in kernel? That's up to the user IMO. For example, suppose this kind of scenario: - the user has a dual boot environment, say, GNU/Linux and Windows. - she uses GRUB installed with the GNU/Linux. - she has made something stupid in the GNU/Linux (e.g. rm -rf /). In the case of GRUB Legacy, this is the end. It's just unbootable, because stage 1.5 may not boot anything besides stage2. In the case of GRUB 2, if the user has pre-loaded chainload.mod onto the core.img, she can still boot the Windows. Honestly, I am more interested in making it possible to use GRUB for setting up a very robust environment. For example: - the user installs a main OS and a rescue OS into a single machine. The latter can be very compact (e.g. puppy, grml, etc.). - she installs another boot loader into the partition for the rescue OS. - she pre-loads chainload.mod in core.img. I think the chainloader is the most realistic, because it is the smallest loader, and GRUB does not need to read a filesystem, thus no filesystem driver is required for loading an OS. Every time I maintain a remote system, I feel the necessity of being prepared for disasters (e.g. filesystem crashes). Rescue mode is one of the tools required for this goal. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Move loader.c out of the kernel
phcoder wrote: > This usage case isn't the main target case. If you embed the loader > (which tend to be quite big) then you already have an overhead from > loader module. Why are you so concerned with overhead of boot.mod? > But on the other hand this forces all the people in other cases to have > boot code in core.img. I want to add preboot hooks and don't want > increment size of kernel. multiboot.mod currently increases the size by > around 11KB. And my patch doesn't restrict you from putting loader in > core.img in any way Even if you add the preboot hooks there, it should only cause size affect in couple of bytes for uncompressed image. Like in following "sketch": ... preboot_handler_address: dd 0 ... cmp [preboot_handler_address], 0 je no_preboot_handler call [preboot_handler_address] no_preboot_handler: ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Move loader.c out of the kernel
I was thinking about something more finished like the possibility of handling multiple preboot and to undo the operations in case of failed or returned boot. Potentially it could be moved to a separate module but it results in a reverse dependency and somewhat ugly code Vesa Jääskeläinen wrote: phcoder wrote: This usage case isn't the main target case. If you embed the loader (which tend to be quite big) then you already have an overhead from loader module. Why are you so concerned with overhead of boot.mod? But on the other hand this forces all the people in other cases to have boot code in core.img. I want to add preboot hooks and don't want increment size of kernel. multiboot.mod currently increases the size by around 11KB. And my patch doesn't restrict you from putting loader in core.img in any way Even if you add the preboot hooks there, it should only cause size affect in couple of bytes for uncompressed image. Like in following "sketch": ... preboot_handler_address: dd 0 ... cmp [preboot_handler_address], 0 je no_preboot_handler call [preboot_handler_address] no_preboot_handler: ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] --build-id= none in newer ld versions PowerPC
On Mon, 2009-01-05 at 01:09 -0600, Jerone Young wrote: > http://lists.gnu.org/archive/html/grub-devel/2008-12/msg00024.html > > It is the attachment. Applied. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split of the normal mode
Yoshinori K. Okuji wrote: On Wednesday 01 April 2009 18:22:46 phcoder wrote: ok, thanks. Now everything is in savannah task tracker. As for command list I added important missing commands to task tracker and skipped not-so-useful ones. As there is some subjectivity involved if you don't agree with my choice just say it. Similar situation is with user's feature requests. I moved the ones that are out of scope of grub2 or already done to "Invalid requests" section. As for other I see none which are priority right now. If you disagree again just say. Thank you so much. It's now so easy to look. :) You're welcome. Some pending patches are still not in the tracker. I added only the ones sent after 25.01.2009 but I'll add more as time permits. Also I omitted my own patches and I'll just ping to my threads on the list. Personally, I think "Add more loaders" and "Add more filesystems" should be removed, because they are not tasks but directions. They could be written at somewhere, but I don't think it is appropriate to put them into the "task manager". From my point of view, tasks must be possible to finish. I agree that these aren't appropriate for task manager. However I don't want to create a separate document for just two lines because this document will be either forgotten or misused. I always have this problem when making order on my computer or in my room. Some stuff is also left which passes to no box and then I have to choose which box to use Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: grub: Fix sparc64 setjmp implementation, update grub_setjmp() attributes.
From: "Yoshinori K. Okuji" Date: Wed, 1 Apr 2009 22:59:03 +0900 > David, I can give you a permission, if you tell me your account on Savannah. It is simply "davem" ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: grub: Fix sparc64 setjmp implementation, update grub_setjmp() attributes.
From: Robert Millan Date: Wed, 1 Apr 2009 15:01:11 +0200 > On Wed, Apr 01, 2009 at 01:17:40AM -0700, David Miller wrote: > > From: "Yoshinori K. Okuji" > > Date: Sat, 28 Mar 2009 23:34:25 +0900 > > > > > On Saturday 28 March 2009 22:39:48 Robert Millan wrote: > > > > Unless there's someone else in the list who is knowledgeable about sparc > > > > assembly and is going to review this part of David's patch, I'm going to > > > > assume it's fine and check it in. > > > > > > > > This also goes for future patches sent by David. So if you will speak, > > > > do it now :-) > > > > > > I know a bit, but not that much. So I vote for that we just trust him. ;) > > > > Ping? > > Committed. Thank you. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH]: Fix sparc64's grub_arch_sync_caches()
1) Window save was done wrongly, but no matter we don't even need to allocate a register window for such a simple routine, there are enough registers available to do this 2) 'flush' operates on at least 8 bytes at a time, as defined by V9, so 8 byte align the extremities of the region and iterate 8 bytes at a time 2009-04-01 David S. Miller * kern/sparc64/cache.S: Fix grub_arch_sync_caches implementation. --- kern/sparc64/cache.S | 26 -- 1 files changed, 12 insertions(+), 14 deletions(-) diff --git a/kern/sparc64/cache.S b/kern/sparc64/cache.S index 2ebb693..1a16add 100644 --- a/kern/sparc64/cache.S +++ b/kern/sparc64/cache.S @@ -1,7 +1,7 @@ /* cache.S - Flush the processor cache for a specific region. */ /* * GRUB -- GRand Unified Bootloader - * Copyright (C) 2005,2007 Free Software Foundation, Inc. + * Copyright (C) 2005,2007,2009 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 @@ -27,17 +27,15 @@ * void grub_arch_sync_caches (void *address, grub_size_t len) */ FUNCTION(grub_arch_sync_caches) -save%o6,-0xC, %o6 ! Get a new register window, -! reserve space on stack for -! %i0, %i1, %i2 -brz,pn %i0,return ! Return if address == 0. - nop -brz,pn %i1,return ! Return if len == 0. - clr %i2! index = 0. -loop: flush %i0 + %i2 ! Flush address + index. -cmp %i1,%i2 ! Compare len & index . -bpos,a,pt %xcc, loop! If len > index, loop. - add%i2,8, %i2 ! Go to next doubleword. -return: ret ! Restore caller's register - restore! window and return. + brz,pn %o1, 2f +add%o0, %o1, %o1 + add %o1, 7, %o1 + andn%o1, 7, %o1 + andn%o0, 7, %o0 + sub %o1, %o0, %o1 +1: subcc %o1, 8, %o1 + bne,pt %icc, 1b +flush %o0 + %o1 +2: retl +nop -- 1.6.2.1.222.g570cc ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH]: Add R_SPARC_OLO10 relocation support.
2009-04-01 David S. Miller
* kern/sparc64/dl.c (grub_arch_dl_relocate_symbols): Add
support for R_SPARC_OLO10 relocations. Fix compile warning for
R_SPARC_WDISP30 case.
---
kern/sparc64/dl.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/kern/sparc64/dl.c b/kern/sparc64/dl.c
index 28ea352..29b8c8a 100644
--- a/kern/sparc64/dl.c
+++ b/kern/sparc64/dl.c
@@ -95,7 +95,7 @@ grub_arch_dl_relocate_symbols (grub_dl_t mod, void *ehdr)
+ entsize * ELF64_R_SYM (rel->r_info));
value = sym->st_value + rel->r_addend;
- switch (ELF64_R_TYPE (rel->r_info))
+ switch (ELF64_R_TYPE (rel->r_info) & 0xff)
{
case R_SPARC_32: /* 3 V-word32 */
if (value & 0x)
@@ -105,8 +105,8 @@ grub_arch_dl_relocate_symbols (grub_dl_t mod, void *ehdr)
break;
case R_SPARC_WDISP30: /* 7 V-disp30 */
if (((value - (Elf64_Addr) addr) & 0x) &&
-((value - (Elf64_Addr) addr) & 0x
-!= 0x))
+(((value - (Elf64_Addr) addr) & 0x)
+!= 0x))
return grub_error (GRUB_ERR_BAD_MODULE,
"Displacement out of 30 bits range");
*addr = (*addr & 0xC000) |
@@ -125,6 +125,12 @@ grub_arch_dl_relocate_symbols (grub_dl_t mod, void *ehdr)
case R_SPARC_64: /* 32 V-xwords64 */
*(Elf64_Xword *) addr = value;
break;
+ case R_SPARC_OLO10:
+ *addr = (*addr & ~0x1fff)
+ | (((value & 0x3ff) +
+ (ELF64_R_TYPE (rel->r_info) >> 8))
+& 0x1fff);
+ break;
default:
return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,
"This relocation (%d) is not implemented
yet",
--
1.6.2.1.222.g570cc
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
