Re: Let core developers "vote" to accept patches.
Johan Rydberg <[EMAIL PROTECTED]> writes: Hi, > In other projects that I've worked on, we've used a system where the > core developers can either give a +1 or a -1 on a contributed patch. > If a patch receives two +1's or more, it is accepted (if there are no > -1's) and committed by one of the developers. Interesting, I like this idea. > This is in no way an attempt to overrun any of our maintainers, it is > just an attempt to make things go a bit smoother and faster in the > times when the maintainers are busy with other things. :-) Although I am a maintainer, I do not know some parts of the code as well as some regular contributors do. I do not feel overrun at all. Actually, this will help me evaluate patches I have no clue about. For example, take your latest patch regarding the build system. It looks sane to me, but I have no idea at all if it is acceptable or not. If I do know about a patch, I hope people remind me often enough to have a look, in case I missed a patch in the past. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Support for reading LVM volumes
At Sun, 13 Aug 2006 17:13:55 +0200, Jeroen Dekkers wrote: > I'm going to work on adding support for LVM to grub-setup now. That's > the last remaining thing in my SoC project. This is done now. This means I've finished all the things for my SoC project. What I've written is a raid module that is able to read RAID arrays and LVM module that can read LVM volumes, so GRUB is able to read files (GRUB modules, kernels, etc) from RAID/LVM. Grub-setup has code that detects that the GRUB root is on a LVM or RAID device and will embed GRUB after the MBR. It will set the prefix so that the GRUB kernel can find the rest of the modules and configuration files. Any comments, bug reports, etc. are welcome. :-) Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Support for reading LVM volumes
Jeroen Dekkers <[EMAIL PROTECTED]> writes: > At Sun, 13 Aug 2006 17:13:55 +0200, > Jeroen Dekkers wrote: >> I'm going to work on adding support for LVM to grub-setup now. That's >> the last remaining thing in my SoC project. > > This is done now. This means I've finished all the things for my SoC > project. What I've written is a raid module that is able to read RAID > arrays and LVM module that can read LVM volumes, so GRUB is able to > read files (GRUB modules, kernels, etc) from RAID/LVM. Grub-setup has > code that detects that the GRUB root is on a LVM or RAID device and > will embed GRUB after the MBR. It will set the prefix so that the GRUB > kernel can find the rest of the modules and configuration files. Congratulations! Thanks a lot for your contribution. :-) -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI disk probing problem
On Saturday 12 August 2006 18:09, Johan Rydberg wrote: > "Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes: > > I don't remember precisely, but I think I only added disk devices but not > > partition devices. On your system, don't disk devices as well as > > partition devices get enumerated? > > I'm not 100% sure about this, but I think EFI does not have to add a > disk device node if there is only a single logical partition on the > disk. Maybe you are right. I hope Mao will comment on this. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Let GCC generate deps with -MD.
On Saturday 12 August 2006 18:07, Johan Rydberg wrote: > Instead of generating the dependencies separately it can be done the > first time a file is compiled, with the -MD option to GCC. That sounds good to me. Thanks, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Support for reading LVM volumes
On Sunday 13 August 2006 21:51, Hollis Blanchard wrote: > On Sun, 2006-08-13 at 20:23 +0200, Jeroen Dekkers wrote: > > At Sun, 13 Aug 2006 11:49:06 -0500, > > > > Hollis Blanchard wrote: > > > What will happen to the google-soc2006 CVS branch when you're done? > > > > It should be merged into the mainline. > > Well, of course. :) My question wasn't "what _should_ happen?" but > rather "what _will_ happen?". > > Who is going to do this? Does this fall outside the scope of your SoC > project? I understand that branches in CVS are extremely cumbersome, so > will this be a difficult process? Anybody can do this. If nobody else wants to do, I will do it... BTW, it is not difficult to merge branches in CVS, if it is done only once. What's difficult in CVS is to track what are merged and what are not merged. In this case, the disadvantage does not matter. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Let GCC generate deps with -MD.
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes: > On Saturday 12 August 2006 18:07, Johan Rydberg wrote: >> Instead of generating the dependencies separately it can be done the >> first time a file is compiled, with the -MD option to GCC. > > That sounds good to me. Committed, with the *.mk files regenerated. Thanks, Johan. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Let core developers "vote" to accept patches.
On Tuesday 15 August 2006 00:37, Johan Rydberg wrote: > In other projects that I've worked on, we've used a system where the > core developers can either give a +1 or a -1 on a contributed patch. > If a patch receives two +1's or more, it is accepted (if there are no > -1's) and committed by one of the developers. You can vote for a patch, but I'm not planning to apply "majority rule" to GRUB. As you can see in various countries, majority-based decisions do not always work very well. I rather believe in aristocracy in software development. Our rules are: - When you are a committer and a patch is trivial enough, you can (and should) check in the patch by yourself. - If not, you should ask others in grub-devel. - I retain final words as the designer of GRUB 2. For some certain parts, I completely rely on other developers. For instance, Hollis would even precede me in PowerPC-specific changes. - If a change is involved with political issues, official maintainers must approve or disapprove. This is required for the GNU Project. Our way is mostly trust-based, and authority-based for important decisions. I do not think this way is working badly. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Support for reading LVM volumes
On Tuesday 15 August 2006 13:30, Jeroen Dekkers wrote: > > I'm going to work on adding support for LVM to grub-setup now. That's > > the last remaining thing in my SoC project. > > This is done now. This means I've finished all the things for my SoC > project. What I've written is a raid module that is able to read RAID > arrays and LVM module that can read LVM volumes, so GRUB is able to > read files (GRUB modules, kernels, etc) from RAID/LVM. Grub-setup has > code that detects that the GRUB root is on a LVM or RAID device and > will embed GRUB after the MBR. It will set the prefix so that the GRUB > kernel can find the rest of the modules and configuration files. > > Any comments, bug reports, etc. are welcome. :-) You are marvelous! It was very painful for me to filter out applicants for SoC, but you got rid of my pain of sin. :) I think the rest is technical documentation. Could you summerize how it works in brief? You can use the wiki or whatever else as you wish. BTW, are you planning to write an article about your work (e.g. osnews.com, free software magazine, etc.)? Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Let core developers "vote" to accept patches.
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes: > Our rules are: > > - When you are a committer and a patch is trivial enough, you can > (and should) check in the patch by yourself. > > - If not, you should ask others in grub-devel. It was for these two scenarios I suggested we could vote on patches. But it might not be needed. I was after all just a suggestion. > - I retain final words as the designer of GRUB 2. For some certain > parts, I completely rely on other developers. For instance, Hollis > would even precede me in PowerPC-specific changes. Agreed. > - If a change is involved with political issues, official > maintainers must approve or disapprove. This is required for the GNU > Project. Of course. ~j ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Support for reading LVM volumes
At Tue, 15 Aug 2006 14:48:41 +0200, Yoshinori K. Okuji wrote: > > On Tuesday 15 August 2006 13:30, Jeroen Dekkers wrote: > > > I'm going to work on adding support for LVM to grub-setup now. That's > > > the last remaining thing in my SoC project. > > > > This is done now. This means I've finished all the things for my SoC > > project. What I've written is a raid module that is able to read RAID > > arrays and LVM module that can read LVM volumes, so GRUB is able to > > read files (GRUB modules, kernels, etc) from RAID/LVM. Grub-setup has > > code that detects that the GRUB root is on a LVM or RAID device and > > will embed GRUB after the MBR. It will set the prefix so that the GRUB > > kernel can find the rest of the modules and configuration files. > > > > Any comments, bug reports, etc. are welcome. :-) > > You are marvelous! It was very painful for me to filter out applicants for > SoC, but you got rid of my pain of sin. :) Thanks. :-) > I think the rest is technical documentation. Could you summerize how it works > in brief? You can use the wiki or whatever else as you wish. http://grub.enbug.org/LVMandRAID I've linked it from the FrontPage. Feel free to ask question or to modify the page to add things if I forgot anything. > BTW, are you planning to write an article about your work (e.g. osnews.com, > free software magazine, etc.)? Not really, I'm afraid there isn't really that much exciting to tell. Maybe I will write down my knowledge about the RAID and LVM disk structures, because currently the only documentation is the source code. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI disk probing problem
Hi, Sorry for late reply because of some other issues, here is my device mapping table, I describe it in tree format blk1(floppy) blkA(BlockDevice cd-rom) blkB(BlockDevice harddisk) |- blk2 (primary partition) |- blk3 (primary partition) |- blk4 (primary partition) |- blk5 (extended partition) | blk6 (logical partition) | blk7 (logical partition) | blk0 (logical partition) | blk8 (logical partition) | blk9 (logical partition) my harddisk is MBR partition type, blk0 is my grub FAT partition. EFI regards all partitions and disk node as block device, only that its type is different, parition block device's subtype is GRUB_EFI_MEDIA_DEVICE_PATH_TYPE, but disk nod is not, harddisk/cdrom nod type is GRUB_EFI_MESSAGING_DEVICE_PATH_TYPE, floppy disk type is GRUB_EFI_ACPI_DEVICE_PATH_TYPE. In order to find root disk, current method is to find harddisk type device's parent device, parent device of block0 is blk5, so it will reagards blk5 as one block device. Actually it is only one extended partition. My patch discards all partition device(GRUB_EFI_MEDIA_DEVICE_PATH_TYPE). thanks bibo,mao blk1:Floppy - Alias (null) Acpi(PNP0A03,0)/Pci(1F|0)/Acpi(PNP0604,0) blkA:BlockDevice - Alias (null) Acpi(PNP0A03,0)/Pci(1F|1)/Ata(Primary,Master) blkB:BlockDevice - Alias (null) Acpi(PNP0A03,0)/Pci(1F|2)/Ata(Primary,Master) blk2:HardDisk - Alias (null) Acpi(PNP0A03,0)/Pci(1F|2)/Ata(Primary,Master)/HD(Part1,SigA3A3A3A3) blk3:HardDisk - Alias (null) Acpi(PNP0A03,0)/Pci(1F|2)/Ata(Primary,Master)/HD(Part2,SigA3A3A3A3) blk4:HardDisk - Alias (null) Acpi(PNP0A03,0)/Pci(1F|2)/Ata(Primary,Master)/HD(Part3,SigA3A3A3A3) blk5:HardDisk - Alias (null) Acpi(PNP0A03,0)/Pci(1F|2)/Ata(Primary,Master)/HD(Part4,SigA3A3A3A3) blk6:HardDisk - Alias (null) Acpi(PNP0A03,0)/Pci(1F|2)/Ata(Primary,Master)/HD(Part4,SigA3A3A3A3)/HD(Part1,Sig) blk7:HardDisk - Alias (null) Acpi(PNP0A03,0)/Pci(1F|2)/Ata(Primary,Master)/HD(Part4,SigA3A3A3A3)/HD(Part2,Sig) blk0:HardDisk - Alias hd31a4d fs0 Acpi(PNP0A03,0)/Pci(1F|2)/Ata(Primary,Master)/HD(Part4,SigA3A3A3A3)/HD(Part3,Sig) blk8:HardDisk - Alias (null) Acpi(PNP0A03,0)/Pci(1F|2)/Ata(Primary,Master)/HD(Part4,SigA3A3A3A3)/HD(Part4,Sig) blk9:HardDisk - Alias (null) Acpi(PNP0A03,0)/Pci(1F|2)/Ata(Primary,Master)/HD(Part4,SigA3A3A3A3)/HD(Part5,Sig) Yoshinori K. Okuji wrote: On Saturday 12 August 2006 18:09, Johan Rydberg wrote: > "Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes: > > I don't remember precisely, but I think I only added disk devices but not > > partition devices. On your system, don't disk devices as well as > > partition devices get enumerated? > > I'm not 100% sure about this, but I think EFI does not have to add a > disk device node if there is only a single logical partition on the > disk. Maybe you are right. I hope Mao will comment on this. Okuji ___ 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
Boot from CD option..
Is grub2 supports "boot from CD" option in menu.lst? What about its status in to-do list if not already there? T.KaruppuSwamy Technical Lead HCL Technologies Ltd. Core Technologies Division J16, Anna Nagar (East) Chennai PIN: 600102 Phone: +91-44-26264206 Extn: 301 DISCLAIMER The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
