Re: [PATCH] add true and false commands
Am Freitag, den 05.06.2009, 15:04 +0200 schrieb Felix Zielcke: Am Freitag, den 05.06.2009, 14:26 +0200 schrieb Marco Gerards: Felix Zielcke fziel...@z-51.de writes: So what should I do now? Placing it in normal.mod or minicmd.mod where it's included in rescue mode or placing it into a true.mod where the size increase would be bigger? minicmd.mod is not a very descriptive name. Better call is truefalse.mod or something like that. minicmd.mod already exists, see commands/minicmd.c (or my first patch). That's where I put it in the first patch. Anyway here's a new one which adds true.mod which gets 1264 bytes big. Thanks Marco that you take the time for it. Commited that one. -- Felix Zielcke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] savedefault
On Sun, Jun 7, 2009 at 10:51 PM, Vladimir 'phcoder' Serbinenkophco...@gmail.com wrote: Hello. Welcome back On Sun, Jun 7, 2009 at 11:35 AM, Beanbean12...@gmail.com wrote: Hi, Actually, I'm thinking about a more generic method to implement this feature with events. The menu viewer fire events at certain circumstance, and we can configure the commands to execute. For example, we could have a menu.select event fire when a menu item is selected, and use something like this in grub.cfg: event add menu.select save_env saved_entry Command save_env saved_entry would be run automatically, no need to patch up the menu items. Often user doesn't want some entries to be saved as default. E.g. single user entries. I know that it's easy to revert to other method but if nearly everyone does your work will be effort for nothing Hi, Now the menuitem support attributes, perhaps we could utilize it to store parameters for the event handler, for example, save/nosave for savedefault, lock/unlock for password, etc. One advantage with the event model is that it can handle password at the same time, for example, we could write something like this: event add menu.select_check password event add menu.commandline_check password password command is run when user tries to select the menu item or enter command line. On Mon, Jun 1, 2009 at 6:48 PM, Vladimir 'phcoder' Serbinenkophco...@gmail.com wrote: Hello. Here is a long-awaited savedefault patch. Works correctly only if my scripting fix is applied -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Bean ___ 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 -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 4/4] Define fields in terms of the Class Code register
Oliver Henshaw oliver.hens...@gmail.com writes: Can you please send in patches in such a way they are recognised as text or inline? Please include a Changelog entry. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] add drivemap support to 30_os-prober.in and use UUIDs
On Sun, Jun 7, 2009 at 5:55 PM, Pavel Roskinpro...@gnu.org wrote: On Sun, 2009-06-07 at 17:37 +0200, Felix Zielcke wrote: Attached patch uses `prepare_grub_to_access_device' to set the root in the generated entrys. And it adds drivemap to the chainload ones, if root isn't (hd0). The Debian grub-installer adds map only with Dos and Windows, should I do the same or is it okay to do it for all? Perhaps it would be better to avoid it when it's not needed. But it may be tricky to determine what bootloader we are using. Let's do it always and eliminate the cases where it's harmful or definitely useless. Drivemapping isn't good per se. It's more like unfortunate need. However it should always be safe to drivemap because AFAIK no OS relies on particular drive ordering except 0x80 being booting drive. However this entry will fail unless my drivemap fix is incorporated -# update-grub helper script. +# grub-mkconfig helper script. Does this needs to be mentioned in ChangeLog? The standard says: 'When you change just comments or doc strings, it is enough to write an entry for the file, without mentioning the functions. Just Doc fixes is enough for the change log.' -- Regards, Pavel Roskin ___ 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
echo and hello bug
I have submitted a bug in to the bugzilla at https://savannah.gnu.org/bugs/?26744 in which hello just hangs. I have tried a few tests around this to see if I can get any output via hello from the command line (from menu pressing C) but I cannot. The problem also occurs if I use echo. Any suggestions on how I might try to fix this (I am happy to test it)? The fact that both hello and echo seem to exhibit the same problem suggests it is not the input as the former is set as a string in the code. James -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] drivemap fixes
On Mon, Jun 8, 2009 at 4:10 AM, Pavel Roskinpro...@gnu.org wrote:
Also, it would be great
if you specify, which exactly problems the patch fixes.
You missed that part because it was in the previous drivemap thread.
It fixes 2 problems: grub2 passes incorrect boot number and %dl not
being restored after int 0x13
As for the fixes to the handler, I think they should be submitted
separately.
They were together because there have already been discussion about
previous version of %dl fix
--
Regards,
Pavel Roskin
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
diff --git a/ChangeLog b/ChangeLog
index cb6fe3f..ff534ce 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,34 @@
+2009-06-08 Vladimir Serbinenko phco...@gmail.com
+
+ Drivemap fixes
+
+ * commands/i386/pc/drivemap.c (grub_get_root_biosnumber_drivemap):
+ new function
+ (grub_get_root_biosnumber_saved): new variable
+ (GRUB_MOD_INIT): register grub_get_root_biosnumber_drivemap
+ (GRUB_MOD_FINI): unregister grub_get_root_biosnumber_drivemap
+ * commands/i386/pc/drivemap_int13h.S (grub_drivemap_handler): restore
+ %dx after the call if necessary
+ * conf/common.rmk (pkglib_MODULES): remove boot.mod
+ (boot_mod_SOURCES): remove
+ (boot_mod_CFLAGS): remove
+ (boot_mod_LDFLAGS): remove
+ * conf/i386-coreboot.rmk (pkglib_MODULES): add boot.mod
+ (boot_mod_SOURCES): new variable
+ (boot_mod_CFLAGS): likewise
+ (boot_mod_LDFLAGS): likewise
+ * conf/i386-efi.rmk: likewise
+ * conf/i386-ieee1275.rmk: likewise
+ * conf/i386-pc.rmk: likewise
+ * conf/powerpc-ieee1275.rmk: likewise
+ * conf/sparc64-ieee1275.rmk: likewise
+ * conf/x86_64-efi.rmk: likewise
+ * include/grub/i386/pc/biosnum.h: new file
+ * lib/i386/pc/biosnum.c: likewise
+ * loader/i386/bsd.c (grub_bsd_get_device): use grub_get_root_biosnumber
+ * loader/i386/multiboot.c (grub_multiboot_get_bootdev): likewise
+ * loader/i386/pc/chainloader.c (grub_chainloader_cmd): likewise
+
2009-06-08 Felix Zielcke fziel...@z-51.de
* commands/true.c: New file. Implement the true and false commands.
diff --git a/commands/i386/pc/drivemap.c b/commands/i386/pc/drivemap.c
index 898fb51..92781a0 100644
--- a/commands/i386/pc/drivemap.c
+++ b/commands/i386/pc/drivemap.c
@@ -23,8 +23,9 @@
#include grub/misc.h
#include grub/disk.h
#include grub/loader.h
+#include grub/env.h
#include grub/machine/memory.h
-
+#include grub/machine/biosnum.h
/* Real mode IVT slot (seg:off far pointer) for interrupt 0x13. */
@@ -356,10 +357,49 @@ uninstall_int13_handler (void)
return GRUB_ERR_NONE;
}
+static int
+grub_get_root_biosnumber_drivemap (void)
+{
+ char *biosnum;
+ int ret = -1;
+ grub_device_t dev;
+
+ biosnum = grub_env_get (biosnum);
+
+ if (biosnum)
+return grub_strtoul (biosnum, 0, 0);
+
+ dev = grub_device_open (0);
+ if (dev dev-disk dev-disk-dev
+ dev-disk-dev-id == GRUB_DISK_DEVICE_BIOSDISK_ID)
+{
+ drivemap_node_t *curnode = map_head;
+ ret = (int) dev-disk-id;
+ while (curnode)
+ {
+ if (curnode-redirto == ret)
+ {
+ ret = curnode-newdrive;
+ break;
+ }
+ curnode = curnode-next;
+ }
+
+}
+
+ if (dev)
+grub_device_close (dev);
+
+ return ret;
+}
+
static grub_extcmd_t cmd;
+static int (*grub_get_root_biosnumber_saved) (void);
GRUB_MOD_INIT (drivemap)
{
+ grub_get_root_biosnumber_saved = grub_get_root_biosnumber;
+ grub_get_root_biosnumber = grub_get_root_biosnumber_drivemap;
cmd = grub_register_extcmd (drivemap, grub_cmd_drivemap,
GRUB_COMMAND_FLAG_BOTH,
drivemap
@@ -374,6 +414,7 @@ GRUB_MOD_INIT (drivemap)
GRUB_MOD_FINI (drivemap)
{
+ grub_get_root_biosnumber = grub_get_root_biosnumber_saved;
grub_loader_unregister_preboot_hook (drivemap_hook);
drivemap_hook = 0;
grub_unregister_extcmd (cmd);
diff --git a/commands/i386/pc/drivemap_int13h.S b/commands/i386/pc/drivemap_int13h.S
index 7a3e8e7..96848fb 100644
--- a/commands/i386/pc/drivemap_int13h.S
+++ b/commands/i386/pc/drivemap_int13h.S
@@ -27,6 +27,11 @@
/* The replacement int13 handler. Preserve all registers. */
FUNCTION(grub_drivemap_handler)
+ /* Save %dx for future restore. */
+ push %dx
+ /* Push flags. Used to simulate interrupt with original flags. */
+ pushf
+
/* Map the drive number (always in DL). */
push %ax
push %bx
@@ -51,11 +56,48 @@ not_found:
pop %bx
pop %ax
- /* Upon arrival to this point the stack must be exactly like at entry.
- This long jump will transfer the caller's stack to the old INT13
- handler, thus making it return directly to the original caller. */
- .byte 0xea
+ cmpb $0x8, %ah
+ jz norestore
+ cmpb $0x15, %ah
+ jz norestore
+
+ /* Restore flags. */
+ popf
+ pushf
+
+ lcall *%cs:INT13H_OFFSET (EXT_C (grub_drivemap_oldhandler))
+
+ push %bp
+ mov %sp, %bp
+
+tail:
+
+ pushf
+ pop %dx
+ mov %dx, 8(%bp)
+
+ pop %bp
+
+ /*
$lib_DATA gets installed to both $libdir/grub and $pkglibdir
Is there any reason why we install the $lib_DATA files (grub-mkconfig_lib and update-grub_lib) to both $libdir/grub and $pkglibdir, e.g. /usr/lib/grub and /usr/lib/grub/i386-pc? In Makefile.in PKGLIB includes $(lib_DATA) -- Felix Zielcke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gracefully ignore inability to retrieve C/H/S on LBA disks
committed On Sun, May 17, 2009 at 3:34 PM, Vladimir 'phcoder' Serbinenkophco...@gmail.com wrote: Hello. Here is a workaround for buggy BIOSes not supplying C/H/S geometry -- Regards Vladimir 'phcoder' Serbinenko -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: echo and hello bug
Vladimir 'phcoder' Serbinenko wrote: On Mon, Jun 8, 2009 at 1:34 PM, James Jarvisjames.jar...@ed.ac.uk wrote: I have submitted a bug in to the bugzilla at https://savannah.gnu.org/bugs/?26744 in which hello just hangs. I have tried a few tests around this to see if I can get any output via hello from the command line (from menu pressing C) but I cannot. The problem also occurs if I use echo. Any suggestions on how I might try to fix this (I am happy to test it)? The fact that both hello and echo seem to exhibit the same problem suggests it is not the input as the former is set as a string in the code. What is your build environment? I build on Ubuntu 9.04 SMP x86_64 on the iMac 9,1 I tend to use a fat binary using - the dev is towards a grub image to work on both 32 and 64 bit macs however I have tested just as 64 bit and it has the same error. As the bug report says I compile and build for efi platform. In OSX the efi.tar.gz is unpacked to MacOSX root (hd0,1)/ and bless the (hd0,1)/efi/grub/grub.efi there. Menus work. Appleloader works. I have attached the script I use to build it. James James -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. makefatgrub.sh Description: application/shellscript ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 0/4] Re: Grub needs to check the programming interface for usb controllers
Here's a second try. I used quilt to manage the patch series but mailed them by hand instead of exporting to a mailbox, and didn't realise that they weren't named as *.patch (otherwise I think the content type would have been fine). I should probably move on to git, but I was a little intimidated by the idea of re-writing history - manipulating a patch series seemed more natural to me. But onwards and upwards. I've removed all changes to trailing whitespace, as requested. There is still a whitespace change in side a comment, something I noticed with syntax highlighting. Thanks, Oliver ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 2/4] Fix inteface definition for ohci
Changelog: * bus/usb/ohci.c: Set interf with correct field. --- bus/usb/ohci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: grub2/bus/usb/ohci.c === --- grub2.orig/bus/usb/ohci.c +++ grub2/bus/usb/ohci.c @@ -128,7 +128,7 @@ grub_ohci_pci_iter (int bus, int device, addr = grub_pci_make_address (bus, device, func, 2); class = grub_pci_read (addr); - interf = class 0xFF; + interf = (class 8) 0xFF; subclass = (class 16) 0xFF; class = 24; ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 3/4] Check usb programming interface
Changelog:
* bus/usb/ohci.c: Check programming interface is ohci. Add grub_dprintf
for symmetry
with bus/usb/uhci.c.
* bus/usb/uhci.c: Check programming interface is uhci. Add interf
variable for
Programming Interface. Print interface with
class/subclass.
---
bus/usb/ohci.c |5 -
bus/usb/uhci.c |8 +---
2 files changed, 9 insertions(+), 4 deletions(-)
Index: grub2/bus/usb/ohci.c
===
--- grub2.orig/bus/usb/ohci.c
+++ grub2/bus/usb/ohci.c
@@ -133,7 +133,7 @@ grub_ohci_pci_iter (int bus, int device,
class = 24;
/* If this is not an OHCI controller, just return. */
- if (class != 0x0c || subclass != 0x03)
+ if (class != 0x0c || subclass != 0x03 || interf != 0x10)
return 0;
/* Determine IO base address. */
@@ -159,6 +159,9 @@ grub_ohci_pci_iter (int bus, int device,
/* Reserve memory for the HCCA. */
o-hcca = (struct grub_ohci_hcca *) grub_memalign (256, 256);
+ grub_dprintf (ohci, class=0x%02x 0x%02x interface 0x%02x base=0x%x\n,
+ class, subclass, interf, o-iobase);
+
/* Check if the OHCI revision is actually 1.0 as supported. */
revision = grub_ohci_readreg32 (o, GRUB_OHCI_REG_REVISION);
grub_dprintf (ohci, OHCI revision=0x%02x\n, revision 0xFF);
Index: grub2/bus/usb/uhci.c
===
--- grub2.orig/bus/usb/uhci.c
+++ grub2/bus/usb/uhci.c
@@ -143,6 +143,7 @@ grub_uhci_pci_iter (int bus, int device,
{
grub_uint32_t class;
grub_uint32_t subclass;
+ grub_uint32_t interf;
grub_uint32_t base;
grub_uint32_t fp;
grub_pci_address_t addr;
@@ -152,11 +153,12 @@ grub_uhci_pci_iter (int bus, int device,
addr = grub_pci_make_address (bus, device, func, 2);
class = grub_pci_read (addr);
+ interf = (class 8) 0xFF;
subclass = (class 16) 0xFF;
class = 24;
/* If this is not an UHCI controller, just return. */
- if (class != 0x0c || subclass != 0x03)
+ if (class != 0x0c || subclass != 0x03 || interf != 0x00)
return 0;
/* Determine IO base address. */
@@ -177,8 +179,8 @@ grub_uhci_pci_iter (int bus, int device,
u-framelist = 0;
u-qh = 0;
u-td = 0;
- grub_dprintf (uhci, class=0x%02x 0x%02x base=0x%x\n,
- class, subclass, u-iobase);
+ grub_dprintf (uhci, class=0x%02x 0x%02x interface 0x%02x base=0x%x\n,
+ class, subclass, interf, u-iobase);
/* Reserve a page for the frame list. */
u-framelist = grub_memalign (4096, 4096);
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 1/4] Minor Cleanup
Changelog:
* bus/usb/uhci.c: Remove un-needed doubled lines.
* bus/usb/ohci.c: Likewise. Change interf to grub_uint32_t. Remove
whitespace inside comment.
---
bus/usb/ohci.c |7 ++-
bus/usb/uhci.c |2 --
2 files changed, 2 insertions(+), 7 deletions(-)
Index: grub2/bus/usb/ohci.c
===
--- grub2.orig/bus/usb/ohci.c
+++ grub2/bus/usb/ohci.c
@@ -118,7 +118,7 @@ grub_ohci_pci_iter (int bus, int device,
{
grub_uint32_t class;
grub_uint32_t subclass;
- int interf;
+ grub_uint32_t interf;
grub_uint32_t base;
grub_pci_address_t addr;
struct grub_ohci *o;
@@ -127,8 +127,6 @@ grub_ohci_pci_iter (int bus, int device,
addr = grub_pci_make_address (bus, device, func, 2);
class = grub_pci_read (addr);
- addr = grub_pci_make_address (bus, device, func, 2);
- class = grub_pci_read (addr);
interf = class 0xFF;
subclass = (class 16) 0xFF;
@@ -171,8 +169,7 @@ grub_ohci_pci_iter (int bus, int device,
frame_interval = grub_ohci_readreg32 (o, GRUB_OHCI_REG_FRAME_INTERVAL);
/* Suspend the OHCI by issuing a reset. */
- grub_ohci_writereg32 (o, GRUB_OHCI_REG_CMDSTATUS, 1); /* XXX: Magic.
- */
+ grub_ohci_writereg32 (o, GRUB_OHCI_REG_CMDSTATUS, 1); /* XXX: Magic. */
grub_millisleep (1);
grub_dprintf (ohci, OHCI reset\n);
Index: grub2/bus/usb/uhci.c
===
--- grub2.orig/bus/usb/uhci.c
+++ grub2/bus/usb/uhci.c
@@ -151,8 +151,6 @@ grub_uhci_pci_iter (int bus, int device,
addr = grub_pci_make_address (bus, device, func, 2);
class = grub_pci_read (addr);
- addr = grub_pci_make_address (bus, device, func, 2);
- class = grub_pci_read (addr);
subclass = (class 16) 0xFF;
class = 24;
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 0/4] Re: Grub needs to check the programming interface for usb controllers
On Mon, 2009-06-08 at 18:45 +0100, oliver.hens...@gmail.com wrote: Here's a second try. I used quilt to manage the patch series but mailed them by hand instead of exporting to a mailbox, and didn't realise that they weren't named as *.patch (otherwise I think the content type would have been fine). I should probably move on to git, but I was a little intimidated by the idea of re-writing history - manipulating a patch series seemed more natural to me. But onwards and upwards. STGit manipulates the patches. It was inspired by quilt. It should be really easy to learn for someone who knows git. I've removed all changes to trailing whitespace, as requested. There is still a whitespace change in side a comment, something I noticed with syntax highlighting. I've applied your patches. The third patch in the series introduced a compile warning due to iobase being a pointer on OHCI. I fixed that. Please note that the ChangeLog is wrapped at the column 72. All non-empty lines except the author's name start with one tab. Please specify thew functions affected by your changes unless the changes are in the top-level code or all over the place. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot take partial mmap
On Fri, Jun 5, 2009 at 11:10 AM, Colin Watsoncjwat...@ubuntu.com wrote: On Fri, Jun 05, 2009 at 03:24:09AM +0200, Vladimir 'phcoder' Serbinenko wrote: On Thu, Jun 4, 2009 at 10:07 PM, Andrey Valyaevd...@osrc.info wrote: PS: latest svn revision (from 2243) failed with message: gcc -Icommands -I./commands -I. -I./include -I./include -Wall -W -Wall -W - Wshadow -Wpointer-arith -Wmissing-prototypes -Wundef - Wstrict-prototypes -g -Os -falign-jumps=1 -falign-loops=1 -falign-functions=1 -m32 -fno-stack-protector -mno-stack-arg-probe -fno-builtin -mrtd -mregparm=3 -m32 -Werror -Wall -MD -c -o search_mod-commands_search.o commands/search.c cc1: warnings being treated as errors commands/search.c: In function 'search_fs': commands/search.c:42: error: generating trampoline in object (requires executable stack) commands/search.c: In function 'grub_cmd_search': commands/search.c:105: error: generating trampoline in object (requires executable stack) make[1]: *** [search_mod-commands_search.o] Error 1 $ gcc --version gcc (Gentoo 4.3.3-r2 p1.1, pie-10.1.5) 4.3.3 This is because of commit 2243 by Robert Millan. The commit was about floppy probing but also added -Wall -Werror to search.mod I myself stepped on this mine once with adding -Wall -Werror to my xnu module. I'll revert this change (only -Werror, not the rest of commit) as it causes build error for all gentoo users. Sorry, Robert, but we can't enable -Werror and still have nested functions. I don't think we should use -Werror at all because different compilers, versions or modifications of same compiler cause different warnings and imho maintaintaining cost is too high and breaks are too frequent. Or perhaps we can enable -Werror only on some compilers? Or perhaps anyone has a better idea You could use -Wno-trampolines (IIRC that's the spelling) on Gentoo's patched GCC; it's generally good to minimise unwanted warnings even if they aren't errors. Here's the macro I use in man-db to add GCC warning options: # man-gcc-warning.m4 serial 1 dnl MAN_GCC_WARNING(WARNING) dnl Add -WWARNING to CFLAGS if it is supported by the compiler. AC_DEFUN([MAN_GCC_WARNING], [man_saved_CFLAGS=$CFLAGS CFLAGS=$CFLAGS -W$1 AC_CACHE_CHECK([that GCC supports -W$1], [AS_TR_SH([man_cv_gcc_warning_$1])], [AS_TR_SH([man_cv_gcc_warning_$1])=no AC_COMPILE_IFELSE([AC_LANG_PROGRAM()], [AS_TR_SH([man_cv_gcc_warning_$1])=yes])]) if test $AS_TR_SH([man_cv_gcc_warning_$1]) = no; then CFLAGS=$man_saved_CFLAGS fi]) # MAN_GCC_WARNING I then use this in configure.ac: if test $GCC = yes then MAN_GCC_WARNING([]) # -W MAN_GCC_WARNING([pointer-arith]) MAN_GCC_WARNING([write-strings]) MAN_GCC_WARNING([strict-prototypes]) MAN_GCC_WARNING([shadow]) MAN_GCC_WARNING([format-security]) MAN_GCC_WARNING([no-missing-field-initializers]) fi Feel free to use and adjust to taste if you want. I think we could use it with -W, -Wall, -Wno-trampolines. Is everybody ok with that? Is this code copyrighted by you? -- Colin Watson [cjwat...@ubuntu.com] ___ 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] hfs+ uuid
On Sun, May 3, 2009 at 6:55 PM, Pavel Roskinpro...@gnu.org wrote: On Sun, 2009-05-03 at 12:42 +0200, Vladimir 'phcoder' Serbinenko wrote: This is a patch to support UUIDs on HFS+. MD5 code is copied from Michael Gorven's patch which is copied from libgcrypt nearly verbatim. Thanks for Cris for the info about how xnu expects UUID to be I suggest that you run all new code through GNU indent. Spacing in 32-(n) will probably need to be fixed manually, as it's a preprocessor directive. Commented out call to to _gcry_burn_stack() should probably be removed. I would prefer that we don't use #undef. Instead, the preprocessor defines should use unique names that never need to be redefined. Setting two environment variables is undocumented. I think rd_string should not be needed. If you need it due to the script engine problems, it's better to fix the script engine. At least please mark that hack as a hack. Perhaps we should consider adding %X support to grub_printf(). I realize that it will increase the core slightly, but if it's just a few bytes, we could accept it. Other modules may use it. Or maybe we could have grub_toupper(), perhaps an inline function? Another thing to consider is whether md5 support should be in a separate file. It would make it possible to reuse md5 for other commands. Here is the improved patch. I deliberately ignored md5 comments because this part will be gone anyway whel Michael Gorven signs his copyright assignment and we incorporate luks patches -- Regards, Pavel Roskin ___ 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] hfs+ uuid
Attachement forgotten
On Mon, Jun 8, 2009 at 10:50 PM, Vladimir 'phcoder'
Serbinenkophco...@gmail.com wrote:
On Sun, May 3, 2009 at 6:55 PM, Pavel Roskinpro...@gnu.org wrote:
On Sun, 2009-05-03 at 12:42 +0200, Vladimir 'phcoder' Serbinenko wrote:
This is a patch to support UUIDs on HFS+. MD5 code is copied from
Michael Gorven's patch which is copied from libgcrypt nearly verbatim.
Thanks for Cris for the info about how xnu expects UUID to be
I suggest that you run all new code through GNU indent. Spacing in
32-(n) will probably need to be fixed manually, as it's a preprocessor
directive.
Commented out call to to _gcry_burn_stack() should probably be removed.
I would prefer that we don't use #undef. Instead, the preprocessor
defines should use unique names that never need to be redefined.
Setting two environment variables is undocumented. I think rd_string
should not be needed. If you need it due to the script engine problems,
it's better to fix the script engine. At least please mark that hack as
a hack.
Perhaps we should consider adding %X support to grub_printf(). I
realize that it will increase the core slightly, but if it's just a few
bytes, we could accept it. Other modules may use it. Or maybe we could
have grub_toupper(), perhaps an inline function?
Another thing to consider is whether md5 support should be in a separate
file. It would make it possible to reuse md5 for other commands.
Here is the improved patch. I deliberately ignored md5 comments
because this part will be gone anyway whel Michael Gorven signs his
copyright assignment and we incorporate luks patches
--
Regards,
Pavel Roskin
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
--
Regards
Vladimir 'phcoder' Serbinenko
diff --git a/commands/xnu_uuid.c b/commands/xnu_uuid.c
new file mode 100644
index 000..51b7ca7
--- /dev/null
+++ b/commands/xnu_uuid.c
@@ -0,0 +1,433 @@
+/* xnu_uuid.c - transform 64-bit serial number
+ to 128-bit uuid suitable for xnu. */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 1995,1996,1998,1999,2001,2002,
+ *2003, 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
+ * 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/types.h
+#include grub/misc.h
+#include grub/mm.h
+#include grub/err.h
+#include grub/dl.h
+#include grub/device.h
+#include grub/disk.h
+#include grub/fs.h
+#include grub/file.h
+#include grub/misc.h
+#include grub/env.h
+#include grub/command.h
+
+struct tohash
+{
+ grub_uint8_t prefix[16];
+ grub_uint64_t serial;
+} __attribute__ ((packed));
+
+/* This prefix is used by xnu and boot-132 to hash
+ together with volume serial. */
+static grub_uint8_t hash_prefix[16]
+ = {0xB3, 0xE2, 0x0F, 0x39, 0xF2, 0x92, 0x11, 0xD6,
+ 0x97, 0xA4, 0x00, 0x30, 0x65, 0x43, 0xEC, 0xAC};
+
+#define rol(x,n) ( ((x) (n)) | ((x) (32-(n))) )
+#define ror(x,n) ( ((x) (n)) | ((x) (32-(n))) )
+
+typedef struct {
+ grub_uint32_t A,B,C,D; /* chaining variables */
+ grub_uint32_t nblocks;
+ grub_uint8_t buf[64];
+ int count;
+} MD5_CONTEXT;
+
+static void
+md5_init( void *context )
+{
+ MD5_CONTEXT *ctx = context;
+
+ ctx-A = 0x67452301;
+ ctx-B = 0xefcdab89;
+ ctx-C = 0x98badcfe;
+ ctx-D = 0x10325476;
+
+ ctx-nblocks = 0;
+ ctx-count = 0;
+}
+
+/* These are the four functions used in the four steps of the MD5 algorithm
+ and defined in the RFC 1321. The first function is a little bit optimized
+ (as found in Colin Plumbs public domain implementation). */
+/* #define FF(b, c, d) ((b c) | (~b d)) */
+#define FF(b, c, d) (d ^ (b (c ^ d)))
+#define FG(b, c, d) FF (d, b, c)
+#define FH(b, c, d) (b ^ c ^ d)
+#define FI(b, c, d) (c ^ (b | ~d))
+
+
+/
+ * transform n*64 grub_uint8_ts
+ */
+static void
+transform ( MD5_CONTEXT *ctx, const unsigned char *data )
+{
+ grub_uint32_t correct_words[16];
+ register grub_uint32_t A = ctx-A;
+ register grub_uint32_t B = ctx-B;
+ register grub_uint32_t C = ctx-C;
+ register grub_uint32_t D = ctx-D;
+ grub_uint32_t *cwp = correct_words;
+
+#ifdef WORDS_BIGENDIAN
+ {
+int i;
+grub_uint8_t *p2, *p1;
+for(i=0, p1=data, p2=(grub_uint8_t*)correct_words; i 16; i++, p2 += 4 )
+{
+ p2[3] = *p1++;
+
Re: [PATCH] add a --disk-module option to grub-install
Am Freitag, den 05.06.2009, 23:26 +0200 schrieb Vladimir 'phcoder'
Serbinenko:
-# generic method (used on coreboot)
+if [ $disk_module = ata ] ; then
+# generic method (used on coreboot and ata mod)
uuid=`$grub_probe --target=fs_uuid --device ${grub_device}`
if [ x${uuid} = x ] ; then
- echo UUID needed on this platform, but the filesystem
containing ${grubdir} does not support UUIDs. 12
+ echo UUID needed on this platform and with ata mod, but
the filesystem containing ${grubdir} does not support UUIDs. 12
IMO it would be better to remove on this platform part.
Otherwise patch looks ok, I will test it tomorrow
Commited with it removed.
On Thu, Jun 4, 2009 at 11:07 PM, Felix Zielckefziel...@z-51.de wrote:
Am Donnerstag, den 04.06.2009, 20:57 +0200 schrieb Felix Zielcke:
Here's a patch which adds --disk-module to grub-install for i386-pc to
make it easier for users to try out ata mod instead of biosdisk.
Args I forgot the actual parsing of the option.
--
Felix Zielcke
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot take partial mmap
On Mon, Jun 08, 2009 at 10:43:42PM +0200, Vladimir 'phcoder' Serbinenko wrote: Is this code copyrighted by you? I think it's really too obvious to be copyrightable, but if it's copyrightable by anyone it's by me, GPLv2 or later. I have an assignment pending although the paperwork doesn't seem to have arrived yet (though I was away for a couple of weeks; maybe I should have another dig through the post pile ...) -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Re: grub-install --root-directory=/mnt /dev/sda1 fails
Am Montag, den 01.06.2009, 21:39 +0200 schrieb Felix Zielcke:
Am Mittwoch, den 06.05.2009, 17:12 +0200 schrieb Vladimir 'phcoder'
Serbinenko:
Don't we already have a function which transforms host directory into
grub
directory? AFAIR we have.
There's just the shell function in grub-mkconfig_lib.in
Here's now a patch wich implements it in util/hostdisk.c and gets used
for core_path_dev in setup ().
But it doestn't work with symlinks.
readlink () can only be used if the file pointed to is a symlink, not if
a symlink is somewhere in between.
coreutils where the readlink binary is from is GPL 3+ but the function
for it uses hash tables and it seems like it would be too much code to
copy just for this.
Here's a new patch which prints out an error if stat () fails.
--
Felix Zielcke
2009-06-08 Felix Zielcke fziel...@z-51.de
* include/grub/util/hostdisk.c
(grub_make_system_path_relative_to_its_root): New function
prototype.
* util/hostdisk.c (grub_make_system_path_relative_to_its_root):
New function.
* util/i386/pc/grub-setup.c (setup): Use
grub_make_system_path_relative_to_its_root to make core_path_dev
relative to the partition.
diff --git a/util/hostdisk.c b/util/hostdisk.c
index a7262dd..0a786ba 100644
--- a/util/hostdisk.c
+++ b/util/hostdisk.c
@@ -1076,3 +1076,39 @@ grub_util_biosdisk_get_grub_dev (const char *os_dev)
return make_device_name (drive, -1, -1);
#endif
}
+
+char *grub_make_system_path_relative_to_its_root (char *path)
+{
+
+ struct stat st;
+ char buf[500], buf2[500];
+ dev_t num;
+ char *p;
+
+ if (stat (path, st) 0)
+return NULL;
+
+ num = st.st_dev;
+ memset (buf, 0 , sizeof (buf));
+ strncpy (buf, path, 500);
+ strcpy (buf2, buf);
+ while (1)
+{
+ p = strrchr (buf, '/');
+ if (p != buf)
+ *p = 0;
+ else *++p = 0;
+
+ if (stat (buf, st) 0)
+ return NULL;
+
+ if (st.st_dev != num)
+ break;
+ strcpy(buf2,buf);
+ if (p - 1 == buf)
+ return path;
+}
+ for (p = buf2; *p != 0; p++)
+path++;
+ return path;
+}
diff --git a/util/i386/pc/grub-setup.c b/util/i386/pc/grub-setup.c
index 997811b..9446fd5 100644
--- a/util/i386/pc/grub-setup.c
+++ b/util/i386/pc/grub-setup.c
@@ -405,6 +405,9 @@ unable_to_embed:
/* Make sure that GRUB reads the identical image as the OS. */
tmp_img = xmalloc (core_size);
core_path_dev = grub_util_get_path (dir, core_file);
+ core_path_dev = grub_make_system_path_relative_to_its_root (core_path_dev);
+ if (core_path_dev == NULL)
+grub_util_error (failed to make path of core.img relative to its root);
/* It is a Good Thing to sync two times. */
sync ();
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] hfs+ uuid
On Mon, 2009-06-08 at 22:50 +0200, Vladimir 'phcoder' Serbinenko wrote: Here is the improved patch. I deliberately ignored md5 comments because this part will be gone anyway whel Michael Gorven signs his copyright assignment and we incorporate luks patches Please consider if it would be better to supply the filesystem UUID on the command line rather than the device name. That would make xnu_uuid leaner and more flexible. I think we need the uuid command that would get the uuid and the xnu_uuid command that would convert it. It would be great if you run xnu_uuid.c through indent. The coding style is quite different from that used elsewhere in GRUB. Or at least please strip trailing spaces. file name required is a wrong error message. It should be device file required. I think it would be better to expand fs and FS in error messages as filesystem. If the variable name is not specified, I think xnu_uuid should just output the UUID without any explanations. Explanations belong to the help, not to the normal output. (void)mod; is not needed. The buf variable in grub_cmd_xnu_uuid() is unused. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Link usb controller struct only when initialised
Commited with small stylistic change: comments start with an uppercase letter and end with 2 spaces On Sun, Jun 7, 2009 at 8:37 PM, Oliver Henshawoliver.hens...@gmail.com wrote: When controller initialisation is aborted in grub_uhci_pci_iter (grub_ohci_pci_iter) control jumps to fail:, where any allocated memory is freed. However, the struct grub_uhci *u (struct grub_ohci *o) for that controller remains linked to the list of UHCI (OHCI) controllers. This causes problems later, when grub iterates over controllers to initialise their ports. The solution is to link only when the usb controller is successfully initialised, and just before returning from the function. This patch is tested with real hardware and with qemu and the rescue image. Thanks, Oliver ___ 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] Link usb controller struct only when initialised
On Tue, 2009-06-09 at 01:57 +0200, Vladimir 'phcoder' Serbinenko wrote: Commited with small stylistic change: comments start with an uppercase letter and end with 2 spaces Thanks! By the way, it would be nice to rewrite uhci.c and ohci.c using GRUB lists (include/grub/list.h). And rewriting usb_keyboard.c would fix the crash when the USB keyboard is missing. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: echo and hello bug
May be of interest - This is the module subset I am using with fat grub efi rev 2202 for 64/32bit efi on Imac81, MacBookPro41, MacBook21. ( ./fatglue.py grub2202fat.efi grub2202-32.efi grub2202-64.efi ) I dont use hello, but echo works. appleldr boot cat cmp chain configfile crc date echo ext2 fixvideo fat fs_uuid gpt gptsync halt help hexdump hfs hfsplus iso9660 linux loopback loadbios lspci ls minicmd memrw ntfs pc pci reboot reiserfs read scsi sleep search sh video videotest xfs. On Mon, Jun 8, 2009 at 11:39 PM, James Jarvis james.jar...@ed.ac.uk wrote: Vladimir 'phcoder' Serbinenko wrote: On Mon, Jun 8, 2009 at 1:34 PM, James Jarvisjames.jar...@ed.ac.uk wrote: I have submitted a bug in to the bugzilla at https://savannah.gnu.org/bugs/?26744 in which hello just hangs. I have tried a few tests around this to see if I can get any output via hello from the command line (from menu pressing C) but I cannot. The problem also occurs if I use echo. Any suggestions on how I might try to fix this (I am happy to test it)? The fact that both hello and echo seem to exhibit the same problem suggests it is not the input as the former is set as a string in the code. What is your build environment? I build on Ubuntu 9.04 SMP x86_64 on the iMac 9,1 I tend to use a fat binary using - the dev is towards a grub image to work on both 32 and 64 bit macs however I have tested just as 64 bit and it has the same error. As the bug report says I compile and build for efi platform. In OSX the efi.tar.gz is unpacked to MacOSX root (hd0,1)/ and bless the (hd0,1)/efi/grub/grub.efi there. Menus work. Appleloader works. I have attached the script I use to build it. James James -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
