Re: Current SVN is broken on x86_64
On Mon, Aug 04, 2008 at 01:02:41AM -0400, Pavel Roskin wrote: I confirm it. And the i386-pc platform grew new warnings: kern/main.c: In function 'grub_set_root_dev': kern/main.c:108: warning: implicit declaration of function 'grub_free' loader/i386/pc/multiboot.c: In function 'grub_multiboot_load_elf32': loader/i386/pc/multiboot.c:165: warning: assignment makes integer from pointer without a cast loader/i386/pc/multiboot.c:168: warning: passing argument 1 of 'grub_memmove' makes pointer from integer without a cast loader/i386/pc/multiboot.c:175: warning: initialization makes pointer from integer without a cast loader/i386/pc/multiboot.c:177: warning: format '%p' expects type 'void *', but argument 6 has type 'Elf32_Addr' loader/i386/pc/multiboot.c:177: warning: format '%p' expects type 'void *', but argument 7 has type 'Elf32_Word' loader/i386/pc/multiboot.c:205: warning: format '%p' expects type 'void *', but argument 5 has type 'grub_addr_t' loader/i386/pc/multiboot.c:205: warning: format '%p' expects type 'void *', but argument 6 has type 'grub_size_t' loader/i386/pc/multiboot.c:205: warning: format '%p' expects type 'void *', but argument 7 has type 'grub_uint32_t' loader/i386/pc/multiboot.c:128: warning: unused variable 'physical_entry_addr' Sorry, my bad. I'll have a look at this. -- 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: Current SVN is broken on x86_64
On Mon, Aug 04, 2008 at 02:31:28AM +0200, Felix Zielcke wrote: I just tried to compile the Debian packages with the currently SVN version and it failed: cc -Iloader/i386/efi -I/home/fz/grub/grub2-1.96+20080804/loader/i386/efi -I. -Iinclude -I/home/fz/grub/grub2-1.96+20080804/include -Wall -W -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes -Wundef -Wstrict-prototypes -g -Os -m64 -fno-stack-protector -mno-stack-arg-probe -fno-builtin -m64 -MD -c -o _linux_mod-loader_i386_efi_linux.o /home/fz/grub/grub2-1.96+20080804/loader/i386/efi/linux.c In file included from /home/fz/grub/grub2-1.96+20080804/loader/i386/efi/linux.c:34: /home/fz/grub/grub2-1.96+20080804/include/grub/pci.h:48:26: error: grub/cpu/pci.h: No such file or directory /home/fz/grub/grub2-1.96+20080804/loader/i386/efi/linux.c: In function 'grub_find_video_card': /home/fz/grub/grub2-1.96+20080804/loader/i386/efi/linux.c:471: warning: implicit declaration of function 'grub_pci_read' So we have grub/i386/pci.h but not grub/x86_64/pci.h. This is my fault, but I think it's too easy to make mistakes with this grub/i386/ vs grub/x86_64/ duplicity. Furthermore, I had a look and some of the x86_64 versions are just stubs that include the i386 one. Why don't we handle this like Linux? They ship a single directory and use #ifdefs where appropiate. That enforces consistency in the dir layout. -- 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: Current SVN is broken on x86_64
On Mon, 2008-08-04 at 11:16 +0200, Robert Millan wrote: Furthermore, I had a look and some of the x86_64 versions are just stubs that include the i386 one. Why don't we handle this like Linux? They ship a single directory and use #ifdefs where appropiate. That enforces consistency in the dir layout. I think we can do it. i386 and x86_64 could be joined into one x86 architecture with common headers and sources. Perhaps the users should still use i386 and x86_64 in configure, but the code should be mostly common. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Current SVN is broken on x86_64
On Mon, Aug 04, 2008 at 08:51:25AM -0400, Pavel Roskin wrote: On Mon, 2008-08-04 at 11:16 +0200, Robert Millan wrote: Furthermore, I had a look and some of the x86_64 versions are just stubs that include the i386 one. Why don't we handle this like Linux? They ship a single directory and use #ifdefs where appropiate. That enforces consistency in the dir layout. I think we can do it. i386 and x86_64 could be joined into one x86 architecture with common headers and sources. Perhaps the users should still use i386 and x86_64 in configure, but the code should be mostly common. Ok, but I think the i386-x86 rename would be overkill. We're already using i386/ headers on x86_64 (for example, when building util/ stuff in grub-pc). It doesn't hurt if we continue doing that IMHO. -- 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] power management on coreboot
On Mon, Aug 04, 2008 at 01:48:33PM +0200, Robert Millan wrote: + /* Bochs, QEMU, etc. */ + for (p = bochs_shutdown; *p || *(p-1); p++) +grub_outb (*p, 0x8900); Ah, mistake here. This would continue if there's a \0 after the string terminator. I guess I'll have to add an explicit call after the loop. -- 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: Current SVN is broken on x86_64
On Mon, 2008-08-04 at 17:11 +0200, Robert Millan wrote: Ok, but I think the i386-x86 rename would be overkill. We're already using i386/ headers on x86_64 (for example, when building util/ stuff in grub-pc). It doesn't hurt if we continue doing that IMHO. Fine with me. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] update-grub for Cygwin
Christian Franke wrote:
Robert Millan wrote:
On Thu, Jul 24, 2008 at 10:39:04PM +0200, Christian Franke wrote:
+
+d=`${grub_probe} -t drive $p 2/dev/null` || exit 0
Please avoid reliing on '-t drive'. It's based on device.map which just
contains guesswork.
prepare_grub_to_access_device() is a much better option.
Yes. Thanks for the info. New version below.
Christian
...
Here a more generic version which allows to specifiy windows system dirs
by /etc/default/grub:GRUB_WINDOWS_DIRS.
Defaults to current SYSTEMDRIVE on Cygwin, and nothing on other OS.
Christian
2008-08-04 Christian Franke [EMAIL PROTECTED]
* conf/common.rmk: Add `10_windows' to `update-grub_SCRIPTS'.
* util/grub.d/10_windows.in: New file.
* util/update-grub.in: Add export of GRUB_WINDOWS_DIRS.
diff --git a/conf/common.rmk b/conf/common.rmk
index 3d3cd8a..3d674a6 100644
--- a/conf/common.rmk
+++ b/conf/common.rmk
@@ -120,7 +120,7 @@ CLEANFILES += update-grub_lib
%: util/grub.d/%.in config.status
./config.status --file=$@:$
chmod +x $@
-update-grub_SCRIPTS = 00_header 10_linux 10_hurd 30_os-prober 40_custom
+update-grub_SCRIPTS = 00_header 10_linux 10_hurd 10_windows 30_os-prober 40_custom
CLEANFILES += $(update-grub_SCRIPTS)
update-grub_DATA += util/grub.d/README
diff --git a/util/grub.d/10_windows.in b/util/grub.d/10_windows.in
new file mode 100644
index 000..0b0bce2
--- /dev/null
+++ b/util/grub.d/10_windows.in
@@ -0,0 +1,104 @@
+#! /bin/sh -e
+
+# update-grub helper script.
+# Copyright (C) 2008 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/.
+
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
+. ${libdir}/grub/update-grub_lib
+
+# List of directories to search for Windows can be specified
+# in @sysconfdir@/default/grub by GRUB_WINDOWS_DIRS, e.g:
+# GRUB_WINDOWS_DIRS=/boot /mnt/win*
+
+dirlist=$GRUB_WINDOWS_DIRS
+
+if [ -z $dirlist ] ; then
+ case `uname 2/dev/null` in
+CYGWIN*)
+ # Cygwin: try current system partition.
+ dirlist=$SYSTEMDRIVE ;;
+*)
+ # Other: do nothing to avoid collision with os-prober.
+ exit 0 ;;
+ esac
+fi
+
+# Test for a file, case-insensitive.
+test_nocase ()
+{
+ local p=
+ if [ $1 = -p ] ; then
+p=t ; shift
+ fi
+ local f=`ls -1 $1 2/dev/null | grep -i '^'$2'$' | sed 1q`
+ test -n $f || return 1
+ test -z $p || echo $1/$f
+}
+
+# Get OS name from boot.ini.
+get_os_name_from_boot_ini ()
+{
+ local ini=`test_nocase -p $1 boot.ini` || return 1
+
+ # Fail if no or more than one partition.
+ test `sed -n 's,^\(\(multi\|scsi\)[^=]*\)=.*$,\1,p' $ini 2/dev/null | \
+sort | uniq | wc -l` = 1 || return 1
+
+ # Search 'default=PARTITION'
+ local part=`sed -n 's,^default=,,p' $ini | sed 's,,/,g;s,[ \t\r]*$,,;1q'`
+ test -n $part || return 1
+
+ # Search 'PARTITION=NAME ...'
+ local name=`sed -n 's,,/,g;s,^'$part'=\([^]*\).*$,\1,p' $ini | sed 1q`
+ test -n $name || return 1
+
+ echo $name
+}
+
+
+for dir in $dirlist ; do
+
+ # Check for Vista Bootmgr.
+ if test_nocase $dir bootmgr bootdir=`test_nocase -p $dir boot`
+ test_nocase $bootdir bcd ; then
+OS=Windows Vista bootmgr
+
+ # Check for NTLDR.
+ elif test_nocase $dir ntldr test_nocase $dir ntdetect.com ; then
+OS=`get_os_name_from_boot_ini $dir` || OS=Windows NT/2000/XP loader
+
+ else
+continue
+ fi
+
+ # Get boot /dev/ice.
+ dev=`${grub_probe} -t device $dir 2/dev/null` || continue
+
+ echo Found $OS on $dir ($dev) 2
+ cat EOF
+menuentry $OS {
+EOF
+
+ prepare_grub_to_access_device $dev | sed 's,^,\t,'
+
+ cat EOF
+ chainloader +1
+}
+EOF
+done
+
diff --git a/util/update-grub.in b/util/update-grub.in
index 8c60c41..eafaa91 100644
--- a/util/update-grub.in
+++ b/util/update-grub.in
@@ -163,7 +163,7 @@ esac
export GRUB_DEVICE GRUB_DEVICE_UUID GRUB_DEVICE_BOOT GRUB_DEVICE_BOOT_UUID GRUB_FS GRUB_FONT_PATH GRUB_PRELOAD_MODULES
# These are optional, user-defined variables.
-export GRUB_DEFAULT GRUB_TIMEOUT GRUB_DISTRIBUTOR GRUB_CMDLINE_LINUX GRUB_CMDLINE_LINUX_DEFAULT GRUB_TERMINAL GRUB_SERIAL_COMMAND GRUB_DISABLE_LINUX_UUID
+export GRUB_DEFAULT GRUB_TIMEOUT GRUB_DISTRIBUTOR GRUB_CMDLINE_LINUX GRUB_CMDLINE_LINUX_DEFAULT GRUB_TERMINAL GRUB_SERIAL_COMMAND GRUB_DISABLE_LINUX_UUID GRUB_WINDOWS_DIRS
rm -f ${grub_cfg}.new
exec ${grub_cfg}.new
___
Grub-devel mailing
Re: [PATCH] update-grub for Cygwin
On Mon, Aug 04, 2008 at 09:46:03PM +0200, Christian Franke wrote: Here a more generic version which allows to specifiy windows system dirs by /etc/default/grub:GRUB_WINDOWS_DIRS. Defaults to current SYSTEMDRIVE on Cygwin, and nothing on other OS. Christian 2008-08-04 Christian Franke [EMAIL PROTECTED] * conf/common.rmk: Add `10_windows' to `update-grub_SCRIPTS'. * util/grub.d/10_windows.in: New file. * util/update-grub.in: Add export of GRUB_WINDOWS_DIRS. Why is this needed? Can't we do something like 'grub-probe -t device c:/ntldr' or so? -- 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: TSC on coreboot (Re: [PATCH] High resolution time/TSC patch v3)
Hi Robert,
Robert Millan [EMAIL PROTECTED] writes:
You forgot the changelog entry :-)
On Sun, Aug 03, 2008 at 09:48:16PM +0200, Robert Millan wrote:
On Mon, Jul 28, 2008 at 10:05:33AM -0700, Colin D Bennett wrote:
+/* Calibrate the TSC based on the RTC. */
+static void
+calibrate_tsc (void)
+{
+ /* First calbrate the TSC rate (relative, not absolute time). */
+ grub_uint64_t start_tsc;
+ grub_uint64_t end_tsc;
+ grub_uint32_t initial_tick;
+ grub_uint32_t start_tick;
+ grub_uint32_t end_tick;
+
+ /* Wait for the start of the next tick;
+ we'll base out timing off this edge. */
+ initial_tick = grub_get_rtc ();
Ah, I see the problem. It calls grub_get_rtc() which in grub-coreboot is
just
a stub.
How about using the interval timer for calibration instead?
Here. With this patch your code works on coreboot too.
Note: AFAICT we can't calculate the epoch without RTC. But then again, this
epoch is just as defined by the time BIOS enables RTC interrupts, so why not
define it ourselves? I propose that we define epoch as the time in which our
TSC code is initialized.
If knowing the time in which BIOS was started is really useful, maybe we could
#ifdef it instead. Though if it's not I'd prefer the simplicity.
If this works and fixes coreboot, it is fine to me ;-)
One comment follows below.
--- ../grub2.tsc/include/grub/i386/pit.h 1970-01-01 01:00:00.0
+0100
+++ ./include/grub/i386/pit.h 2008-08-04 01:22:12.0 +0200
@@ -0,0 +1,19 @@
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2008 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/.
+ */
+
+extern void grub_pit_wait (grub_uint16_t tics);
Please us an inclusion guard.
--
Marco
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] update-grub for Cygwin
Robert Millan wrote: On Mon, Aug 04, 2008 at 09:46:03PM +0200, Christian Franke wrote: Here a more generic version which allows to specifiy windows system dirs by /etc/default/grub:GRUB_WINDOWS_DIRS. Defaults to current SYSTEMDRIVE on Cygwin, and nothing on other OS. Christian 2008-08-04 Christian Franke [EMAIL PROTECTED] * conf/common.rmk: Add `10_windows' to `update-grub_SCRIPTS'. * util/grub.d/10_windows.in: New file. * util/update-grub.in: Add export of GRUB_WINDOWS_DIRS. Why is this needed? Can't we do something like 'grub-probe -t device c:/ntldr' or so? It is not needed for standard installations with ntldr on SYSTEMDRIVE (C:). The ability to specify GRUB_WINDOWS_DIRS is added to support non-standard installations. It also allows to use 10_windows on other OS if os-prober is not available. Christian ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Drivemap module
Javier Martín [EMAIL PROTECTED] writes: After your latest replay, I reevaluated my stubbornness WRT some of your advices, and I've changed a few things: - Variables are now declared (and, if possible, initialized) before precondition checks, even simple ones. The install_int13_handler function has not been modified, however, since I find it a bit nonsensical to put bunch of declarations without an obvious meaning just after the else line: grub_uint32_t *ivtslot; grub_uint16_t *bpa_freekb; grub_size_t total_size; grub_uint16_t payload_sizekb; grub_uint8_t *handler_base; int13map_node_t *handler_map; grub_uint32_t ivtentry; Please understand me correctly. Code just has to be written according to our coding standards before it can and will be included. We can discuss things endlessly but we will simply stick to the GNU Coding Standards as you might expect. I hope you can appreciate that all code of GRUB has the same coding style, if you like this style or not. - Only one declaration per line: even though C is a bit absurd in not recognizing T* as a first class type and instead thinking of * as a qualifier to the variable name; and even though my code does not incur into such ambiguities. - Comments moved as you required, reworded as needed - Extensive printf showing quasi-help in the show mode trimmed down to just the first sentence. - Internal helper functions now use the standard error handling, i.e. return grub_error (err, fmt, ...) - Comment about the strange void type instead of void* rephrased to be clearer Thanks a lot! There is, however, one point in which I keep my objection: comparisons between a variable and a constant should be of the form CONSTANT == variable and not in the reverse order, since an erroneous but quite possible change of == for = results in a compile-time error instead of a _extremely_ difficult to trace runtime bug. Such kind of bugs are quite excruciating to find in userspace applications within an IDE, so I can't even consider the pain to debug them in a bootloader. I understand your concern, nevertheless, can you please change it? WRT accepting raw BIOS disk numbers, I agree with you in principle, but I'm keeping the functionality for now, since I don't quite like the drivemap (hd0) (hd1) syntax - which device is which?. I'd rather have something akin to drivemap (hd0) (bios:hd1), but I want to hear the opinions of people in this list. I personally do not care a lot if BIOS disk numbers are used. Although I do not see why it is useful. As for the syntax, I would prefer something more GRUB2ish, like: map --bios=(hd0) --os=(hd1) Or so, perhaps the long argument names can be chosen in a more clever way :-) The new version of the patch is attached, and here is my suggested CLog: 2008-08-XX Javier Martin [EMAIL PROTECTED] (newline) * commands/i386/pc/drivemap.c : New file. * commands/i386/pc/drivemap_int13h.S : New file. * conf/i386-pc.rmk (pkglib_MODULES) : Added drivemap.mod (drivemap_mod_SOURCES) : New variable (drivemap_mod_ASFLAGS) : Likewise (drivemap_mod_CFLAGS) : Likewise (drivemap_mod_LDFLAGS) : Likewise * include/grub/loader.h (grub_loader_register_preboot) : New function prototype. Register a new pre-boot handler No need how the change is used or why it was added. (grub_loader_unregister_preboot) : Likewise. Unregister handler Same here. (grub_preboot_hookid) : New typedef. Registered hook handle Same here. * kern/loader.c (grub_loader_register_preboot) : New function. (grub_loader_unregister_preboot) : Likewise. (preboot_hooks) : New variable. Linked list of preboot hooks Same here. (grub_loader_boot) : Call the list of preboot-hooks before the actual loader What's the `'? Please do not add a space before the : Some comments can be found below. Can you please fix the code mention in the review and similar code? I really want the code to be just like any other GRUB code. Please understand that we have to maintain this in the future. If everyone would use his own codingstyle, GRUB would become unmaintainable. Index: commands/i386/pc/drivemap.c === --- commands/i386/pc/drivemap.c (revisión: 0) +++ commands/i386/pc/drivemap.c (revisión: 0) @@ -0,0 +1,417 @@ +/* drivemap.c - command to manage the BIOS drive mappings. */ +/* + * GRUB -- GRand Unified Bootloader + * Copyright (C) 2008 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
Re: bug-grub
Hi, Robert Millan [EMAIL PROTECTED] writes: [s/bug-grub/grub-devel/] What does everyone think? IIRC Okuji wants to remain using bug-grub for our bugs. If not, we should change this IMO. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] PXE support for grub2
Hi,
Bean [EMAIL PROTECTED] writes:
This patch add the (pxe) device that can be used to load files using
the pxe service. It also add a user land command pxe that can be used
to show pxe information as well as set some parameter.
Great! :-)
To create a pxe boot image:
./grub-mkimage -d . -o core.img pxe
cat pxeboot.img core.img g2pxe
g2pxe is the pxe boot file, copy it to tftp server, you also need to
copy *.mod, fs.lst, command.lst, moddep.lst and grub.cfg to /boot/grub
directory in the tftp server.
To test it in qemu, copy the files to directory such as /tftp, then:
qemu -boot n -tftp /tftp -bootp /g2pxe
usage for pxe command:
pxe info
Show information about pxe, like block size, client ip, etc.
pxe blksize size
Set block size. tftp transfer in trunks of bytes, the size can be
configured. The minimum size is 512, which is also the default. The
maximum size is 1432. Normally, you can increase download speed by
setting larger block size, but some old tftp server may not support
it. Also, qemu doesn't support size other than 512.
pxe unload
Unload the pxe runtime environment.
Actually, I would prefer:
pxe --info
pxe --blksize=size
pxe --unload
You kinda reimplemented an argument parser. The advantage of the
build in argument parser is that it supports generation of --help
documentation and it supports tab completion.
Please note that this patch depends on my other patch bufio, you need
to apply that first.
2008-07-30 Bean [EMAIL PROTECTED]
* boot/i386/pc/pxeboot.S: Use drive number 0x7F for pxe.
Isn't it in _start?
* boot/i386/pc/pxeboot.S (_start): Use drive number 0x7F for pxe.
* conf/i386-pc.rmk (kernel_img_HEADERS): Add machine/pxe.h.
(pkglib_MODULES): Add pxe.mod and pxecmd.mod.
(pxe_mod_SOURCES): New macro.
(pxe_mod_CFLAGS): Likewise.
(pxe_mod_LDFLAGS): Likewise.
(pxecmd_mod_SOURCES): Likewise.
(pxecmd_mod_CFLAGS): Likewise.
(pxecmd_mod_LDFLAGS): Likewise.
* kern/i386/pc/startup.S (grub_pxe_scan): New function.
(grub_pxe_call): Likewise.
* kern/i386/pc/init.c (make_install_device): Set root to (pxe) for pxe
boot.
* include/grub/disk.h (grub_disk_dev_id): Add GRUB_DISK_DEVICE_PXE_ID.
* commands/i386/pc/pxecmd.c: New file.
* disk/i386/pc/pxe.c: Likewise.
* include/grub/i386/pc/pxe.h: Likewise.
--
Bean
diff --git a/boot/i386/pc/pxeboot.S b/boot/i386/pc/pxeboot.S
index 7f2a143..62a4fb2 100644
--- a/boot/i386/pc/pxeboot.S
+++ b/boot/i386/pc/pxeboot.S
@@ -26,7 +26,8 @@
.globl _start; _start:
/* Root drive will default to boot drive */
-movb$0xFF, %dh
+movb $0xFF, %dh
+movb $0x7F, %dl
Please update the copyright year of files you change. IIRC this file
is not from this year. I often forget to mention this, but it applies
in general.
/* Jump to the real world */
ljmp$0, $0x8200
diff --git a/commands/i386/pc/pxecmd.c b/commands/i386/pc/pxecmd.c
new file mode 100755
index 000..6bf3045
--- /dev/null
+++ b/commands/i386/pc/pxecmd.c
@@ -0,0 +1,92 @@
+/* pxe.c - command to control the pxe driver */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2008 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/normal.h
+#include grub/dl.h
+#include grub/arg.h
+#include grub/err.h
+#include grub/misc.h
+#include grub/machine/pxe.h
+
+static void
+print_ip (grub_uint32_t ip)
+{
+ int i;
+
+ for (i = 0; i 3; i++)
+{
+ grub_printf (%d., ip 0xFF);
+ ip = 8;
+}
+ grub_printf (%d, ip);
+}
+
+static grub_err_t
+grub_cmd_pxe (struct grub_arg_list *state __attribute__ ((unused)),
+ int argc, char **args)
+{
+ if (! grub_pxe_pxenv)
+return grub_error (GRUB_ERR_FILE_NOT_FOUND, no pxe environment);
+
+ if ((argc == 0) || (! grub_strcmp (args[0], info)))
+{
+ grub_printf (blksize : %d\n, grub_pxe_blksize);
+ grub_printf (client ip : );
+ print_ip (grub_pxe_your_ip);
+ grub_printf (\nserver ip : );
+ print_ip (grub_pxe_server_ip);
+ grub_printf (\ngateway ip : );
+ print_ip (grub_pxe_gateway_ip);
+ grub_printf (\n);
+}
+ else if (! grub_strcmp (args[0], blksize))
Re: bug-grub
On Mon, Aug 04, 2008 at 10:54:19PM +0200, Marco Gerards wrote: Hi, Robert Millan [EMAIL PROTECTED] writes: [s/bug-grub/grub-devel/] What does everyone think? IIRC Okuji wants to remain using bug-grub for our bugs. If not, we should change this IMO. I'd like to remain using bug-grub for bugs, too. But for GRUB 2 bugs instead of GRUB Legacy ones. -- 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] update-grub for Cygwin
On Mon, Aug 04, 2008 at 10:40:02PM +0200, Christian Franke wrote: Robert Millan wrote: On Mon, Aug 04, 2008 at 09:46:03PM +0200, Christian Franke wrote: Here a more generic version which allows to specifiy windows system dirs by /etc/default/grub:GRUB_WINDOWS_DIRS. Defaults to current SYSTEMDRIVE on Cygwin, and nothing on other OS. Christian 2008-08-04 Christian Franke [EMAIL PROTECTED] * conf/common.rmk: Add `10_windows' to `update-grub_SCRIPTS'. * util/grub.d/10_windows.in: New file. * util/update-grub.in: Add export of GRUB_WINDOWS_DIRS. Why is this needed? Can't we do something like 'grub-probe -t device c:/ntldr' or so? It is not needed for standard installations with ntldr on SYSTEMDRIVE (C:). The ability to specify GRUB_WINDOWS_DIRS is added to support non-standard installations. It also allows to use 10_windows on other OS if os-prober is not available. Why not have the user write a custom entry then? I think it clutters the user interface to add options for everything. If a corner case (boot a non native disk, can't use os-prober) can be supported by creating a new config file, why not do that? It was the whole reason for designing update-grub to be easily extensible. -- 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: conf/i386.rmk
Robert Millan [EMAIL PROTECTED] writes: On Sun, Aug 03, 2008 at 09:28:39PM +0200, Robert Millan wrote: Hi, I'm thinking that we have quite a bit of duplicate stuff in each of the 4 i386 ports (cpuid, pci, serial, etc) that could well live in a firmware-agnostic conf/i386.rmk file. This would simplify things and make them easier to maintain. What do you think? Btw, I think grub-emu could go there too. The only arch-specific thing in it AFAICS is cpuid.mod. Right, seems fine to me. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Drivemap module
Javier Martín wrote: You understand my concern, but seemingly do not understand that in order to conform to the Holy Coding Style you are asking me to write code that can become buggy (and with a very hard to trace bug) with a simple deltion! (point: did you notice that last word _without_ a spelling checker? Now try to do so in a multithousand-line program). well, maybe a bit off topic. But I can't imagine how, after code is written, I could accidentally delete an = character even when editing it. I prefer the (to me) intuitive meaning of (variable == value) in my own code. That particular problem has never bitten me. Although, in C++ coding style, a lot more local variables are const and therefore the error could be caught by the compiler anyway. It seems like an odd paranoia to choose. Say, take uint32_t. It's only a one-character deletion to become int32_t and then there is subtle breakage. htons and many other functions with similar names and suffixes. Etc.? It's half C language and culture, and half inevitable in programming, IMHO. point[2]: I half did notice the typo (only half because I've trained myself not to be too distracted by people's spelling), and I'm generally more precise when looking at code (maybe). ;-) Anyway, since they are more likely to maintain the code in the long run than you, in general, the question is whether the code is more likely to become buggy by their hacking on it, if it follows project coding style or someone else's (your) safer coding style. Likely it's safer if using a consistent programming style. Although I personally don't see that it's very helpful to have a style that makes things down to the order of == arguments be consistent within the project; haphazard only slows reading the tiniest bit, and I don't think it makes a different what order the arguments are... -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Drivemap module
Hi there and thanks for playing The Game!
El lun, 04-08-2008 a las 20:50 -0400, Isaac Dupree escribió:
Javier Martín wrote:
You understand my concern, but seemingly do not understand that in order
to conform to the Holy Coding Style you are asking me to write code that
can become buggy (and with a very hard to trace bug) with a simple
deltion! (point: did you notice that last word _without_ a spelling
checker? Now try to do so in a multithousand-line program).
well, maybe a bit off topic.
But I can't imagine how, after code is written, I could
accidentally delete an = character even when editing it.
I prefer the (to me) intuitive meaning of (variable ==
value) in my own code. That particular problem has never
bitten me. Although, in C++ coding style, a lot more local
variables are const and therefore the error could be
caught by the compiler anyway. It seems like an odd
paranoia to choose. Say, take uint32_t. It's only a
one-character deletion to become int32_t and then there is
subtle breakage. htons and many other functions with
similar names and suffixes. Etc.? It's half C language and
culture, and half inevitable in programming, IMHO.
Sigh... Maybe I'm just a bit paranoid because I have been bitten by
similar problems (not in ifs, but mainly in loop condition checks) and
they were painstakingly difficult to hunt down even in a good IDE like
Netbeans: I sometimes considered the possibility of my computer having
lost all sense of logic because I saw it singlestep into the wrong
branch until I noticed the = instead of ==. True, the possibilities of
causing such a change are very low.
point[2]: I half did notice the typo (only half because
I've trained myself not to be too distracted by people's
spelling), and I'm generally more precise when looking at
code (maybe). ;-)
So I thought, but even my own code dodges me at times, not to speak of
others' code...
Anyway, since they are more likely to maintain the code in
the long run than you, in general, the question is whether
the code is more likely to become buggy by their hacking on
it, if it follows project coding style or someone else's
(your) safer coding style. Likely it's safer if using a
consistent programming style. Although I personally don't
see that it's very helpful to have a style that makes things
down to the order of == arguments be consistent within the
project; haphazard only slows reading the tiniest bit, and I
don't think it makes a different what order the arguments are...
Hmm... I was partially expecting a flamefest to start. Pity ^^
Well, let's spill a little napalm: the GNU style bracing is extremely
silly!! Why the hell are the if and else blocks indented differently
in this example?
if (condition)
return 0;
else
{
return -1;
}
Nah, I'm not really bringing that issue, I was just joking, and in fact
I'm reconsidering my objections to the operator== arguments order rule,
even though I still consider my style safer and more sensible. If
someone else wants to express their opinion on that issue, do it fast
before I completely submit to Master Marco's will :D
Habbit
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
