Re: Switching to git?
On Thu, Dec 06, 2007 at 12:45:48PM -0500, Pavel Roskin wrote: Other GNU projects have switched to git. Savannah supports git. The list of the GNU projects using git is pretty impressive: http://git.sv.gnu.org/gitweb/ Savannah support was the main concern raised by Okuji last time a proposal to switch away from CVS was brought up. It's good that this is solved. I myself have no objection. I'd prefer svn, but that's not supported by Savannah yet, and anything is better than CVS IMO. In the event that we decide to migrate to svn in the future, though, is there an easy path from git to svn? -- 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: New module to detect vmware
On Thu, Dec 06, 2007 at 02:19:25PM +0100, Martin Haaß wrote: Hi all! I tried to build a module to detect vmware. Attached is the module and a test grub.cfg It is basically working though I have some questions: can i use the return value of the function (e.g. vmware_detect) to give back a value or am I supposed to always return something like GRUB_ERR_NONE? is there a script to add a module to the makefile or do I have to copy/paste it? if I use this: if vmware_detect = 1; then set foo=1 else set foo=0 fi I get syntax error and unknown command in an infinite loop is this expected? It should not be a problem with my module, as it also happend while testing a environment variable. So, is it a problem with my if-syntax? As per GCS, it'd be better if this avoided referring to a propietary product more than necessary for the functionality. How about making this a generic detection command (with a similar interface to the cpuid one), such that detection for other virtual environments (e.g. qemu) can potentially be added? * VMWARE detection code taken from * http://chitchat.at.infoseek.co.jp/vmware/backdoor.html Is there any copyright-significant code taken from there? Which license? -- 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: BTS overhaul
No response? Does anybody object if I proceed? On Thu, Dec 06, 2007 at 01:01:23PM +0100, Robert Millan wrote: Hi! I'd like to overhaul the GRUB BTS in Savannah so that it can be used to track bugs in (or feature requests for) GRUB 2. What I propose to do is review all bugs, and: - If the bug is obviously specific to GRUB Legacy, close it. - If the bug was found in GRUB Legacy, but might apply to GRUB 2, prompt the submitter to reproduce it there (and close it). I don't think the BTS in its current state is any useful to us; patches and bug reports are currently overwhelming the mailing list, which make it less useful for actual discussion. Comments? -- 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] Move NTFS compression support to new module ntfscomp
On Fri, Nov 30, 2007 at 02:58:11AM +0800, Bean wrote: Hi, This patch move NTFS compression function to a standalone module ntfscomp. To access NTFS compression file, you just need to load ntfscomp dynamically: insmod ntfscomp Compression support is not needed most of the time. In some situation, the size of kernel image is limited (like rom), and it's nice to be able to shrink the over-sized ntfs module. Nice. I see that you made some unrelated corrections in your patch, e.g.: - unsigned us; + grub_uint16_t us; could you include these in ChangeLog ? Also, would be nice if you could use inline attachment for patches in the future (I hope it's not a nuissance; I ask because this makes it easier to make context replies). Thank you -- 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] Fix for linker build ID in Fedora 8
Is this fixed now? On Mon, Nov 26, 2007 at 08:06:27AM -0500, Pavel Roskin wrote: On Mon, 2007-11-26 at 13:54 +0100, Lubomir Kundrak wrote: On Mon, 2007-11-26 at 07:35 -0500, Pavel Roskin wrote: The objcopy test exists to detect certain breakage in objcopy. I'm not sure that testing it in the condition that it only copies .text is sufficient to find the original problem. Surely, that will need some software archeology. The test comes from GRUB 1. Anyway, I'll rather test objcopy under conditions close to those used in the build process. To be honest, I'm not completely sure either. OK, I understand that you also want the test to pass on native x86_64. I'll try to find more information about the original objcopy problem and make a fix that addresses both the build ID issue and the x86_64 issue. And what's the build ID for? Why do we want to keep it? It basically makes it possible to match an executable or library with its core dump and sources it was compiled for. The latter is achieved by placing the sources to build-specific directory. Fair enough. I've been helped by Fedora's debuginfo more than once. I understand it's OK to strip build ID from anything that is used in the real boot (whether it's affected by the new objcopy bug or not), as we want space saving and we cannot debug it in gdb. -- Regards, Pavel Roskin -- 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] Move NTFS compression support to new module ntfscomp
Ok. 2007-12-12 Bean [EMAIL PROTECTED] * conf/common.rmk (pkgdata_MODULES): Add ntfscomp.mod. (ntfscomp_mod_SOURCES): New variable. (ntfscomp_mod_CFLAGS): Likewise. (ntfscomp_mod_LDFLAGS): Likewise. * conf/i386-pc.rmk (grub_setup_SOURCES): Add fs/ntfscomp.c. (grub_probe_SOURCES): Likewise. (grub_emu_SOURCES): Likewise. * conf/i386-efi.rmk (grub_probe_SOURCES): Add fs/ntfscomp.c. (grub_emu_SOURCES): Likewise. * conf/i386-linuxbios.rmk (grub_probe_SOURCES): Add fs/ntfscomp.c. (grub_emu_SOURCES): Likewise. * conf/powerpc-ieee1275.rmk (grub_probe_SOURCES): Add fs/ntfscomp.c. (grub_emu_SOURCES): Likewise. * fs/ntfs.c (grub_ntfscomp_func): New variable. (read_run_list): Renamed to grub_ntfs_read_run_list. (decomp_nextvcn): Moved to ntfscomp.c. (decomp_getch): Likewise. (decomp_get16): Likewise. (decomp_block): Likewise. (read_block): Likewise. (read_data): Partially moved to ntfscomp.c. (fixup): Change unsigned to grub_uint16_t. (read_mft): Change unsigned long to grub_uint32_t. (read_attr): Likewise. (read_data): Likewise. (read_run_data): Likewise. (read_run_list): Likewise. (read_mft): Likewise. * fs/ntfscomp.c: New file. * include/grub/ntfs.h: New file. Index: conf/common.rmk === RCS file: /sources/grub/grub2/conf/common.rmk,v retrieving revision 1.17 diff -u -p -r1.17 common.rmk --- conf/common.rmk 18 Nov 2007 06:41:45 - 1.17 +++ conf/common.rmk 29 Nov 2007 18:23:10 - @@ -81,7 +81,7 @@ update-grub_DATA += util/grub.d/README # Filing systems. pkgdata_MODULES += fshelp.mod fat.mod ufs.mod ext2.mod ntfs.mod\ minix.mod hfs.mod jfs.mod iso9660.mod xfs.mod affs.mod \ - sfs.mod hfsplus.mod + sfs.mod hfsplus.mod ntfscomp.mod # For fshelp.mod. fshelp_mod_SOURCES = fs/fshelp.c @@ -108,6 +108,11 @@ ntfs_mod_SOURCES = fs/ntfs.c ntfs_mod_CFLAGS = $(COMMON_CFLAGS) ntfs_mod_LDFLAGS = $(COMMON_LDFLAGS) +# For ntfscomp.mod. +ntfscomp_mod_SOURCES = fs/ntfscomp.c +ntfscomp_mod_CFLAGS = $(COMMON_CFLAGS) +ntfscomp_mod_LDFLAGS = $(COMMON_LDFLAGS) + # For minix.mod. minix_mod_SOURCES = fs/minix.c minix_mod_CFLAGS = $(COMMON_CFLAGS) Index: conf/i386-efi.rmk === RCS file: /sources/grub/grub2/conf/i386-efi.rmk,v retrieving revision 1.24 diff -u -p -r1.24 i386-efi.rmk --- conf/i386-efi.rmk 18 Nov 2007 06:41:45 - 1.24 +++ conf/i386-efi.rmk 29 Nov 2007 18:23:11 - @@ -36,7 +36,7 @@ grub_probe_SOURCES = util/grub-probe.c\ partmap/pc.c partmap/apple.c partmap/gpt.c \ fs/ufs.c fs/minix.c fs/hfs.c fs/jfs.c fs/ntfs.c kern/fs.c \ kern/env.c fs/fshelp.c fs/xfs.c fs/affs.c fs/sfs.c fs/hfsplus.c \ - disk/lvm.c disk/raid.c grub_probe_init.c + fs/ntfscomp.c disk/lvm.c disk/raid.c grub_probe_init.c # For grub-emu. grub_emu_DEPENDENCIES = grub_script.tab.c grub_script.tab.h\ @@ -50,7 +50,7 @@ grub_emu_SOURCES = commands/boot.c comma disk/loopback.c \ fs/affs.c fs/ext2.c fs/fat.c fs/fshelp.c fs/hfs.c fs/iso9660.c \ fs/jfs.c fs/minix.c fs/sfs.c fs/ufs.c fs/xfs.c fs/hfsplus.c \ - fs/ntfs.c \ + fs/ntfs.c fs/ntfscomp.c \ io/gzio.c \ kern/device.c kern/disk.c kern/dl.c kern/elf.c kern/env.c \ kern/err.c \ Index: conf/i386-linuxbios.rmk === RCS file: /sources/grub/grub2/conf/i386-linuxbios.rmk,v retrieving revision 1.3 diff -u -p -r1.3 i386-linuxbios.rmk --- conf/i386-linuxbios.rmk 18 Nov 2007 06:41:45 - 1.3 +++ conf/i386-linuxbios.rmk 29 Nov 2007 18:23:14 - @@ -60,7 +60,7 @@ grub_probe_SOURCES = util/grub-probe.c\ partmap/pc.c partmap/apple.c partmap/gpt.c \ fs/ufs.c fs/minix.c fs/hfs.c fs/jfs.c fs/ntfs.c kern/fs.c \ kern/env.c fs/fshelp.c fs/xfs.c fs/affs.c fs/sfs.c fs/hfsplus.c \ - disk/lvm.c disk/raid.c grub_probe_init.c + fs/ntfscomp.c disk/lvm.c disk/raid.c grub_probe_init.c # For grub-emu. grub_emu_DEPENDENCIES = grub_script.tab.c grub_script.tab.h\ @@ -74,7 +74,7 @@ grub_emu_SOURCES = commands/boot.c comma disk/host.c disk/loopback.c disk/raid.c disk/lvm.c \ fs/affs.c fs/ext2.c fs/fat.c fs/fshelp.c fs/hfs.c fs/iso9660.c \ fs/jfs.c fs/minix.c fs/sfs.c fs/ufs.c fs/xfs.c fs/hfsplus.c \ -
Re: Switching to git?
Quoting Robert Millan [EMAIL PROTECTED]: I myself have no objection. I'd prefer svn, but that's not supported by Savannah yet, and anything is better than CVS IMO. In the event that we decide to migrate to svn in the future, though, is there an easy path from git to svn? I believe git-svn (included with git) should be able to do it. I'm quite sure it would work fine for linear history, but things may be trickier if branches are used. However, I think nobody would want to go from git to svn. Alone the ability to work on more than one patch at once is like getting an extra dimension, something that very few would want to give up. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Convert grub2 kernel core.img to linux kernel format
On Fri, Dec 07, 2007 at 12:13:03AM +0800, Bean wrote: Hi, Added a new file boot/i386/pc/lnxboot.S, which will compile into Could you make this boot/i386/lnxboot.S ? In principle, this should work on other firmware (except maybe EFI). It'd also be good to include it in the makefile for at least i386-linuxbios. -- 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?
Robert Millan [EMAIL PROTECTED] writes: I myself have no objection. I'd prefer svn, but that's not supported by Savannah yet, and anything is better than CVS IMO. In the event that we decide to migrate to svn in the future, though, is there an easy path from git to svn? I doubt that you'll want to come back to SVN after you get used to GIT. I thought it was going to be hard to learn but it was really easy and there's a lot of documentation about it available. -- 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: Convert grub2 kernel core.img to linux kernel format
Ok. 2007-12-12 Bean [EMAIL PROTECTED] * conf/i386-pc.rmk (pkgdata_IMAGES): Add lnxboot.img. (lnxboot_img_SOURCES): New variable. (lnxboot_img_ASFLAGS): Likewise. (lnxboot_img_LDFLAGS): Likewise. * conf/i386-linuxbios.rmk (pkgdata_PROGRAMS): Add lnxboot.img (lnxboot_img_SOURCES): New variable. (lnxboot_img_ASFLAGS): Likewise. (lnxboot_img_LDFLAGS): Likewise. * boot/i386/lnxboot.S: New file. Index: conf/i386-pc.rmk === RCS file: /sources/grub/grub2/conf/i386-pc.rmk,v retrieving revision 1.94 diff -u -p -r1.94 i386-pc.rmk --- conf/i386-pc.rmk18 Nov 2007 06:41:45 - 1.94 +++ conf/i386-pc.rmk6 Dec 2007 15:56:02 - @@ -5,7 +5,7 @@ COMMON_CFLAGS = -fno-builtin -mrtd -mreg COMMON_LDFLAGS = -m32 -nostdlib # Images. -pkgdata_IMAGES = boot.img diskboot.img kernel.img pxeboot.img +pkgdata_IMAGES = boot.img diskboot.img kernel.img pxeboot.img lnxboot.img # For boot.img. boot_img_SOURCES = boot/i386/pc/boot.S @@ -22,6 +22,11 @@ diskboot_img_SOURCES = boot/i386/pc/disk diskboot_img_ASFLAGS = $(COMMON_ASFLAGS) diskboot_img_LDFLAGS = $(COMMON_LDFLAGS) -Wl,-N,-Ttext,8000 +# For lnxboot.img. +lnxboot_img_SOURCES = boot/i386/lnxboot.S +lnxboot_img_ASFLAGS = $(COMMON_ASFLAGS) +lnxboot_img_LDFLAGS = $(COMMON_LDFLAGS) -Wl,-N,-Ttext,6000 + # For kernel.img. kernel_img_SOURCES = kern/i386/pc/startup.S kern/main.c kern/device.c \ kern/disk.c kern/dl.c kern/file.c kern/fs.c kern/err.c \ Index: conf/i386-linuxbios.rmk === RCS file: /sources/grub/grub2/conf/i386-linuxbios.rmk,v retrieving revision 1.3 diff -u -p -r1.3 i386-linuxbios.rmk --- conf/i386-linuxbios.rmk 18 Nov 2007 06:41:45 - 1.3 +++ conf/i386-linuxbios.rmk 12 Dec 2007 16:15:45 - @@ -5,7 +5,12 @@ COMMON_CFLAGS = -ffreestanding -mrtd -mr COMMON_LDFLAGS = -nostdlib -static -lgcc # Images. -pkgdata_PROGRAMS = kernel.elf +pkgdata_PROGRAMS = kernel.elf lnxboot.img + +# For lnxboot.img. +lnxboot_img_SOURCES = boot/i386/lnxboot.S +lnxboot_img_ASFLAGS = $(COMMON_ASFLAGS) +lnxboot_img_LDFLAGS = -m32 -nostdlib -Wl,-N,-Ttext,6000 # For kernel.elf. kernel_elf_SOURCES = kern/i386/linuxbios/startup.S kern/i386/linuxbios/init.c \ Index: boot/i386/lnxboot.S === RCS file: /sources/grub/grub2/boot/i386/lnxboot.S,v diff -Nu boot/i386/lnxboot.S --- /dev/null 2007-12-07 07:38:42.252044265 +0800 +++ boot/i386/lnxboot.S 2007-12-06 23:49:09.359375000 +0800 @@ -0,0 +1,292 @@ +/* -*-Asm-*- */ +/* + * GRUB -- GRand Unified Bootloader + * Copyright (C) 1999,2000,2001,2002,2005,2006,2007 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 + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * GRUB is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with GRUB. If not, see http://www.gnu.org/licenses/. + */ + +#include grub/boot.h +#include grub/machine/boot.h +#include grub/machine/kernel.h + +.file lnxboot.S + +#define CODE_ADDR 0x6000 +#define CODE_LENG (code_end - start) +#define DATA_ADDR ((GRUB_BOOT_MACHINE_KERNEL_ADDR) + 0x200) + +#define BLCK_LENG 0x4000 + + .text + +.code16 + +.globl start, _start + +data_start: + pushw %cs + popw%ds + xorl%eax, %eax + xorl%ebx, %ebx + calldata_next + +data_next: + popw%bx + movw%cs, %ax + shll$4, %eax + leal0x200 + data_start - data_next(%ebx,%eax), %eax + movzbl setup_sects - data_next(%bx), %ecx + shll$9, %ecx + addl%ecx, %eax + movl%eax, code32_start - data_next(%bx) + + jmp linux_next + + . = data_start + 0x1F1 + +setup_sects: + .byte (CODE_LENG 9) +root_flags: + .word 0 +syssize: + .word 0 +swap_dev: + .word 0 +ram_size: + .word 0 +vid_mode: + .word 0 +root_dev: + .word 0 +boot_flag: + .word 0xAA55 + +start: +_start: + + jmp linux_code + + .ascii HdrS // Header signature + .word 0x0203 // Header version number + +realmode_swtch: + .word 0, 0// default_switch, SETUPSEG +start_sys_seg: + .word 0x1000 // obsolete +version_ptr: + .word 0 // version string ptr +type_of_loader: +
Re: Switching to git?
* Otavio Salvador wrote, On 12/12/07 15:03: Robert Millan [EMAIL PROTECTED] writes: I myself have no objection. I'd prefer svn, but that's not supported by Savannah yet, and anything is better than CVS IMO. In the event that we decide to migrate to svn in the future, though, is there an easy path from git to svn? I doubt that you'll want to come back to SVN after you get used to GIT. I thought it was going to be hard to learn but it was really easy and there's a lot of documentation about it available. Git was very hard a while ago, but the porcelain (as it is called) is much improved. Sam ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
On Wed, Dec 12, 2007 at 10:36:17AM -0500, Pavel Roskin wrote: Quoting Robert Millan [EMAIL PROTECTED]: I myself have no objection. I'd prefer svn, but that's not supported by Savannah yet, and anything is better than CVS IMO. In the event that we decide to migrate to svn in the future, though, is there an easy path from git to svn? I believe git-svn (included with git) should be able to do it. I'm quite sure it would work fine for linear history, but things may be trickier if branches are used. However, I think nobody would want to go from git to svn. Alone the ability to work on more than one patch at once is like getting an extra dimension, something that very few would want to give up. Just to make myself clear, I didn't mean to argue that we'll want to migrate from git to svn (I have yet to build an opinion of git myself). However, I think it's very important that we have the option to do it in case we want to. Being trapped somewhere you're not fond of is, like, bad thing you know :-) -- 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: BTS overhaul
On Dec 12, 2007 10:37 PM, Robert Millan [EMAIL PROTECTED] wrote: No response? Does anybody object if I proceed? This is a very good idea, many old items are inappropriate anyway. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: BTS overhaul
On Wed, Dec 12, 2007 at 03:37:28PM +0100, Robert Millan wrote: No response? Does anybody object if I proceed? Did anyone comment on the trac-based solution I mentioned? If someone did, I missed it, sorry. -- Jordi Mallach Pérez -- Debian developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Convert grub2 kernel core.img to linux kernel format
On second thoughts,the original patch is better, because lnxboot.img works with core.img, which depends on boot.img, kernel.img and grub-mkimage that exist only in i386-pc. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
