Re: [PATCH] add a --disk-module option to grub-install

[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." 1>&2
+  echo "UUID needed on this platform and with ata mod, but
the filesystem containing ${grubdir} does not support UUIDs." 1>&2
IMO it would be better to remove "on this platform" part.
Otherwise patch looks ok, I will test it tomorrow
On Thu, Jun 4, 2009 at 11:07 PM, Felix Zielcke 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
>
>



-- 
Regards
Vladimir 'phcoder' Serbinenko


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] support of hfsx ( case comparaison )

[Pavel Roskin]

On Fri, 2009-06-05 at 21:23 +0200, Michael Scherer wrote:

> Ok, I have taken in account your remark. Here is another patch.

I've applied your patch with two fixes.  Somehow you interchanged the
values of GRUB_HFSPLUSX_BINARYCOMPARE and GRUB_HFSPLUSX_CASEFOLDING.
GRUB_HFSPLUSX_BINARYCOMPARE is 0xBC and GRUB_HFSPLUSX_CASEFOLDING is
0xCF.  The values are actually abbreviations.

I wonder if you have tested your patch.  I have tested the final patch
on both case-sensitive and case-insensitive filesystems, and it appears
to be OK.

Also, it should not be needed to call an inline function from
grub_hfsplus_iterate_dir().  It's easier to calculate it once for the
filesystem at the mount time.

-- 
Regards,
Pavel Roskin


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] support of hfsx ( case comparaison )

[Vladimir 'phcoder' Serbinenko]

On Fri, Jun 5, 2009 at 9:23 PM, Michael Scherer wrote:
>
>>
>> We may need to use a comparison table as in hfs.c, as least for the
>> first 256 Unicode characters, but it's a separate issue.
>
> That a little bit too complex for me, I have just patched grub for the
> simplest case, and for the issue I faced on my own computer.
It's actually a problem with grub_strcasecmp since it doesn't take
utf8 into account. HFS+ unlike HFS uses Unicode (UTF-16 normalisation
form d to be exact) so no need for special handling here. Improving
strcasecmp is possible and may even be compact. Even if unicode counts
a lot of alphabets only few are bicameral. AFAIK main ones are Latin,
Greek, Cyrillic and Armenian. I hope that in most cases the lowercase
conversion can be done with some simple arithmetic operations
>
> --
> Michael Scherer
>
> ___
> 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: porting Grub to Xen

[Ferenc Wagner]

"Vladimir 'phcoder' Serbinenko"  writes:

>> Neither have I, but xen-devel says MiniOS is BSD, and should be
>> acceptable for Grub.
>
> If it's under MIT or new BSD license it is. However no code with
> unclear licensing can be used in grub2

The mini-os code has been reviewed and gained an explicit BSD license
just now to clear this issue up.

>> Actually, I wonder if Grub could do any better booting paravirtual
>> domains: you said Grub already knows how to boot Linux, it's even
>> multiboot compliant, but I'm not sure that really helps much in this
>> situation, where it has to replace a PV image with another.
>
> It really depends on how much xen is similar to normal environment.
> Unfortunately I have no deep knowledge of xen

Neither have I, but I'm willing to dig up info on this, just provide
some explicit questions, please.  Anyway, I've got the IRC logs of nyu
promising to get Grub going on Xen for me. :)  On the other hand, Grub
0.97 has been ported to Xen already, the code is available in the Xen
tree under stubdom/grub{.patches}, if you are willing to take a look.
-- 
Regards,
Feri.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] support of hfsx ( case comparaison )

[Michael Scherer]

Le mercredi 03 juin 2009 à 17:23 -0400, Pavel Roskin a écrit :
> Hello!
> 
> I think the ChangeLog needs to be improved.  It's immodest to claim
> "complete" support for something.  It's a very strong statement.  It's
> better to say "improve".  Or better yet, let's be specific.  Also please
> spell check the entry.  "insensitive" and "insentive" is not the same.

Hi, 

Sorry, I am far from being a native english speaker, so that's why some
badly translated expression slipped in and I didn't paid much attention
to the changelog, I was more concerned by the code formating.

> You want the former.   Please end sentences with a period.  I would
> write the ChangeLog entry as:
> 
>   * fs/hfsplus.c: Use case sensitive comparison for hfsx when
>   required by the filesystem settings.
> 
> Actually, it would be better to list the functions involved.  I just
> want to show how long descriptions can be improved.
>
> I also prefer not to use any negative logic, and it's easier to get it
> wrong.  Humans are notoriously bad at logic.  Let's have
> grub_hfsplus_is_case_sensitive().  I would write it like this:
> 
> static inline int
> grub_hfsplus_is_case_sensitive (struct grub_hfsplus_data *data)
> {
>   if ((grub_be_to_cpu16 (data->volheader.magic) == GRUB_HFSPLUSX_MAGIC)
>   && (data->catalog_cmp_key == GRUB_HFSPLUSX_BINARYCOMPARE))
> return 1;
>   else
> return 0;
> }
> 
> No need to handle unknown magic numbers.

Ok, I have taken in account your remark. Here is another patch.


> 
> We may need to use a comparison table as in hfs.c, as least for the
> first 256 Unicode characters, but it's a separate issue.

That a little bit too complex for me, I have just patched grub for the
simplest case, and for the issue I faced on my own computer. 

-- 
Michael Scherer
diff --git a/ChangeLog b/ChangeLog
index 60ed1a6..5b29a7c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2009-06-05  Michael Scherer  
+
+	* fs/hfsplus.c (grub_hfsplus_iterate_dir, grub_hfsplus_is_case_sensitive): 
+	use case sensitive comparison for hfsx when required by the filesystem 
+	settings.
+	(grub_hfsplus_mount) : copy filesystem setting for case
+	sensitive comparison.
+
 2009-06-05  Vladimir Serbinenko  
 
 	* conf/i386-pc.rmk (efiemu_mod_CFLAGS): remove -Werror -Wall
diff --git a/fs/hfsplus.c b/fs/hfsplus.c
index 69794c9..1c559ee 100644
--- a/fs/hfsplus.c
+++ b/fs/hfsplus.c
@@ -99,6 +99,13 @@ struct grub_hfsplus_btheader
   grub_uint32_t last_leaf_node;
   grub_uint16_t nodesize;
   grub_uint16_t keysize;
+  grub_uint32_t total_nodes;
+  grub_uint32_t free_nodes;
+  grub_uint16_t reserved1;
+  grub_uint32_t clump_size;  /* ignored */
+  grub_uint8_t btree_type;
+  grub_uint8_t key_compare;
+  grub_uint32_t attributes;
 } __attribute__ ((packed));
 
 /* The on disk layout of a catalog key.  */
@@ -164,6 +171,9 @@ enum grub_hfsplus_filetype
 GRUB_HFSPLUS_FILETYPE_REG_THREAD = 4
   };
 
+#define GRUB_HFSPLUSX_BINARYCOMPARE 0xCF
+#define GRUB_HFSPLUSX_CASEFOLDING   0xBC
+
 /* Internal representation of a catalog key.  */
 struct grub_hfsplus_catkey_internal
 {
@@ -224,6 +234,7 @@ struct grub_hfsplus_data
   /* This is the offset into the physical disk for an embedded HFS+
  filesystem (one inside a plain HFS wrapper).  */
   int embedded_offset;
+  int catalog_cmp_key;
 };
 
 static grub_dl_t my_mod;
@@ -464,6 +475,7 @@ grub_hfsplus_mount (grub_disk_t disk)
 
   data->catalog_tree.root = grub_be_to_cpu32 (header.root);
   data->catalog_tree.nodesize = grub_be_to_cpu16 (header.nodesize);
+  data->catalog_cmp_key = header.key_compare;
 
   if (! grub_hfsplus_read_file (&data->extoverflow_tree.file, 0,
 sizeof (struct grub_hfsplus_btnode),
@@ -694,6 +706,16 @@ grub_hfsplus_btree_search (struct grub_hfsplus_btree *btree,
 }
 }
 
+static inline int
+grub_hfsplus_is_case_sensitive (struct grub_hfsplus_data *data)
+{
+  if ((grub_be_to_cpu16 (data->volheader.magic) == GRUB_HFSPLUSX_MAGIC)
+ && (data->catalog_cmp_key == GRUB_HFSPLUSX_BINARYCOMPARE))
+return 1;
+  else
+return 0;
+}
+
 static int
 grub_hfsplus_iterate_dir (grub_fshelp_node_t dir,
 			  int NESTED_FUNC_ATTR
@@ -772,7 +794,8 @@ grub_hfsplus_iterate_dir (grub_fshelp_node_t dir,
 	catkey->name[i] = grub_be_to_cpu16 (catkey->name[i]);
 
   /* hfs+ is case insensitive.  */
-  type |= GRUB_FSHELP_CASE_INSENSITIVE;
+  if (!grub_hfsplus_is_case_sensitive (dir->data))
+  type |= GRUB_FSHELP_CASE_INSENSITIVE;
 
   /* Only accept valid nodes.  */
   if (grub_strlen (filename) == grub_be_to_cpu16 (catkey->namelen))
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re[2]: 'password' command in GRUB 2?

[Julien RANC]

Hello,

>> Previous attempts I have found:
>>
>>  http://lists.gnu.org/archive/html/grub-devel/2007-08/msg00034.html
>>    "[PATCH] password command implementation", Julien RANC, August 2007
>>  http://lists.gnu.org/archive/html/grub-devel/2008-05/msg00135.html
>>    "[RFC] Grub2 lock and password implementation", Julien Ranc, May 2008
> I don't know if he has copyright assignment. If he doesn't, copyright
> assignment takes a lot of time

I have no copyright assignment. If there is anything I can do to help
integrating that feature, please tell me, as I see no problem in that,
and I have currently no plan to continue this work.

If I remember correctly, I had improved on the first patch to include
most of the remarks. I'll have a look if I can find back the modified
patch, and send it to the list for anyone to have it.

-- 
Julien RANC.



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: 'password' command in GRUB 2?

[Vladimir 'phcoder' Serbinenko]

On Fri, Jun 5, 2009 at 7:36 PM, Colin Watson wrote:
> Hi,
>
> I was asked today whether GRUB 2 had a 'password' command yet, as it's
> more or less the last major feature regression from GRUB Legacy from our
> point of view. I see from the Subversion repository that it doesn't yet,
> but there have been a number of attempts in the past. Rather than
> reinventing the wheel, if we were to look at pushing this up the hill to
> inclusion, where would be the best place to start?
Once I merge savedefault password protection is the last feature
needed for debian to migrate (according to Robert Millan)
>
> Previous attempts I have found:
>
>  http://lists.gnu.org/archive/html/grub-devel/2007-08/msg00034.html
>    "[PATCH] password command implementation", Julien RANC, August 2007
>  http://lists.gnu.org/archive/html/grub-devel/2008-05/msg00135.html
>    "[RFC] Grub2 lock and password implementation", Julien Ranc, May 2008
I don't know if he has copyright assignment. If he doesn't, copyright
assignment takes a lot of time
>  http://lists.gnu.org/archive/html/grub-devel/2008-08/msg00308.html
>    "Idea: implementation of the password command", Bean, August 2008
>  http://lists.gnu.org/archive/html/grub-devel/2009-02/msg00376.html
>    "Menu locks / password authentication", Robert Millan, February 2009
>
> I agreed with Robert in the last link above that it would be best to
> implement lock/password first and worry about something more extensible
> later if required (on the "you ain't gonna need it" principle),
Yes but I'm uncomfortable with authntication handled in scripts. We
all know SQL injection problems. The main question is whether we want
something simple to use or something very extendable. My approach
would be:
http://lists.gnu.org/archive/html/grub-devel/2009-03/msg00156.html
> Thanks,
>
> --
> 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

'password' command in GRUB 2?

[Colin Watson]

Hi,

I was asked today whether GRUB 2 had a 'password' command yet, as it's
more or less the last major feature regression from GRUB Legacy from our
point of view. I see from the Subversion repository that it doesn't yet,
but there have been a number of attempts in the past. Rather than
reinventing the wheel, if we were to look at pushing this up the hill to
inclusion, where would be the best place to start?

Previous attempts I have found:

  http://lists.gnu.org/archive/html/grub-devel/2007-08/msg00034.html
"[PATCH] password command implementation", Julien RANC, August 2007
  http://lists.gnu.org/archive/html/grub-devel/2008-05/msg00135.html
"[RFC] Grub2 lock and password implementation", Julien Ranc, May 2008
  http://lists.gnu.org/archive/html/grub-devel/2008-08/msg00308.html
"Idea: implementation of the password command", Bean, August 2008
  http://lists.gnu.org/archive/html/grub-devel/2009-02/msg00376.html
"Menu locks / password authentication", Robert Millan, February 2009

I agreed with Robert in the last link above that it would be best to
implement lock/password first and worry about something more extensible
later if required (on the "you ain't gonna need it" principle), but the
threads on the subject have mostly seemed to end up in interface design
discussions rather than just emulating the working design from GRUB
Legacy (modulo using a non-broken hash function) for now.

Is there still substantial disagreement among the GRUB developers about
this, or would it be worthwhile pursuing something that basically just
does what the GRUB Legacy code did? In that case, it seems that Julien's
code in
http://lists.gnu.org/archive/html/grub-devel/2007-08/msg00034.html, with
the review comments incorporated, would be a reasonable place to start?

Thanks,

-- 
Colin Watson   [cjwat...@ubuntu.com]


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: multiboot take partial mmap

[Colin Watson]

On Fri, Jun 05, 2009 at 06:45:54PM +0200, Robert Millan wrote:
> Why exactly does gcc generate a warning because of nested functions?  Is
> there no way to fix this?

It's a Gentoo-specific patch:

  
http://sources.gentoo.org/viewcvs.py/gentoo/src/patchsets/gcc/4.4.0/gentoo/00_all_gcc-trampolinewarn.patch?rev=1.1&view=markup

-- 
Colin Watson   [cjwat...@ubuntu.com]


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: multiboot take partial mmap

[Robert Millan]

On Fri, Jun 05, 2009 at 03:24:09AM +0200, Vladimir 'phcoder' Serbinenko wrote:
> > 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

Unfixed warnings have given us MUCH worse problems than build failures.

I'm talking countless hours of debugging here.

Why exactly does gcc generate a warning because of nested functions?  Is
there no way to fix 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: [PATCH] add true and false commands

[Felix Zielcke]

Am Freitag, den 05.06.2009, 15:29 +0200 schrieb Marco Gerards:
> Oh, I didn't know minicmd.mod.  Is it useful to have one instead of
> a few separate modules?  Space of these smaller modules is not really
> a concern to me.

Bean split the commands out from kernel.
So especially help and lsmod are in rescue mode only avaible if
minicmd.mod gets embed into core.img, where size does matter.

That's why Vladimir suggest normal.mod or sh.mod. But sh.mod just
contains the parser/lexer so I don't think that's a solution.
I'm now now that sure what to do but I think I just make it now a
seperate true.mod like in the last patch.
-- 
Felix Zielcke



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] drivemap fixes

[Vladimir 'phcoder' Serbinenko]

Hello. As suggested by Javier Martín I move this to a new thread. This
patch fixes some problems with determining bios number of a disk.
biosnum is in boot.mod because it's where it will cause the least of
possible core.img increase (3 of 5 loaders on pc need biosnum).
Thisforced to move boot.mod to platform-specific files but this
inflexibility of build system is a subject for another patch

-- 
Regards
Vladimir 'phcoder' Serbinenko
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 
 #include 
 #include 
+#include 
 #include 
-
+#include 
 
 
 /* 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..ba31a9c 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
+
+postamble:	
+	
+	pushf
+	pop 	%dx
+	mov 	%dx, 8(%bp)
+
+	pop	%bp
+	
+	/* Restore %dx.  */
+	pop 	%dx
+	iret
+
+norestore:
+
+	/* Restore flags.  */
+	popf
+	pushf
+
+	lcall *%cs:INT13H_OFFSET (EXT_C (grub_drivemap_oldhandler))
+
+	push 	%bp
+	mov 	%sp, %bp
+	
+	/* Save %dx.  */
+	mov 	%dx, 2(%bp)
 
+	jmp postamble
+	
 /* Far pointer to the old handler.  Stored as a CS:IP in the style of real-mode
IVT entries (thus PI:SC in mem).  */
 VARIABLE(grub_drivemap_oldhandler)
diff --git a/conf/common.rmk b/conf/common.rmk
index 3e59c3a..b328bc4 100644
--- a/conf/common.rmk
+++ b/conf/common.rmk
@@ -353,19 +353,13 @@ pkglib_MODULES += minicmd.mod extcmd.mod hello.mod handler.mod	\
 	loopback.mod fs_uuid.mod configfile.mod echo.mod	\
 	terminfo.mod test.mod blocklist.mod hexdump.mod		\
 	read.mod sleep.mod loadenv.mod crc.mod parttool.mod	\
-	pcpart.mod memrw.mod boot.mod normal.mod sh.mod lua.mod	\
-	gptsync.mod
+	pcpart.mod memrw.mod normal.mod sh.mod lua.mod gptsync.mod
 
 # For gptsync.mod.
 gptsync_mod_SOURCES = commands/gptsync.c
 gptsync_mod_CFLAGS = $(COMMON_CFLAGS)
 gptsync_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
-# For boot.mod.
-boot_mod_SOURCES = commands/boot.c
-boot_mod_CFLAGS = $(COMMON_CFLAGS)
-boot_mod_LDFLAGS = $(COMMON_LDFLAGS)
-
 # For minicmd.mod.
 minicmd_mod_SOURCES = commands/minicmd.c
 minicmd_mod_CFLAGS = $(COMMON_CFLAGS)
diff --git a/conf/i386-coreboot.rmk b/conf/i386-coreboot.rmk
index 2f768c0..483f279 100644
--- a/conf/i386-coreboot.rmk
+++ b/conf/i386-coreboot.rmk
@@ -109,6 +109,12 @@ pkglib_MODULES = linux.mod multiboot.mod 		\
 	halt.mod datetime.mod date.mod datehook.mod	\
 	lsmmap.mod mmap.mod
 
+# For boot.mod.
+pkglib_MODULES += boot.mod 
+boot_mod_SOURCES = commands/boot.c
+boot_mod_CFLAGS = $(COMMON_CFLAGS)
+boot_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
 # For mmap.mod.
 mmap_mod_SOURCES = mmap/mmap.c mmap/i386/uppermem.c mmap/i386/m

Re: status grub2 port of grub-legasy map command

[Javier Martín]

I think you should move this patch to a new thread, first because most
people in the list seem to no longer watch this one, and second because
it touches many files apart from drivemap itself. That said, I still
don't see the situation in which such an override would be used.

Oh, and I would rather see disk->dev->id == GRUB_DISK_DEVICE_BIOSDISK_ID
than a strcmp with a magic string literal.
-- 
-- Lazy, Oblivious, Recurrent Disaster -- Habbit


signature.asc
Description: Esto es una parte de mensaje firmado digitalmente
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] RFC: allow compilation without target libc

[Vladimir 'phcoder' Serbinenko]

This patch greatly simplifies compiling on freebsd-amd64 and possibly
other systems. Would be nice to get in into mainstream fastly. Concern
about multiboot2.h however remains

On Sat, May 23, 2009 at 1:33 AM, Pavel Roskin wrote:
> ChangeLog:
>
>        * configure.ac: Define GRUB_SOURCE to identify GRUB sources
>        in include/multiboot2.h.  Use "-nostdlib" when testing target
>        compiler.
>        * include/multiboot2.h: Use GRUB types and definitions.  Provide
>        compatibility layer when GRUB_SOURCE is not defined.
>        * loader/i386/pc/multiboot2.c: Include multiboot2.h last to make
>        sure that config.h was included first.
>        * loader/multiboot2.c: Likewise.
>        * loader/multiboot_loader.c: Likewise.
> ---
>
>  configure.ac                |    3 ++-
>  include/multiboot2.h        |   24 +++-
>  loader/i386/pc/multiboot2.c |    2 +-
>  loader/multiboot2.c         |    2 +-
>  loader/multiboot_loader.c   |    2 +-
>  5 files changed, 20 insertions(+), 13 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 98cd841..af60603 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -161,6 +161,7 @@ test "x$GCC" = xyes || AC_MSG_ERROR([GCC is required])
>
>  AC_GNU_SOURCE
>  AC_SYS_LARGEFILE
> +AC_DEFINE([GRUB_SOURCE], [1], [Define when compiling GRUB sources.])
>
>  # Identify characteristics of the host architecture.
>  AC_C_BIGENDIAN
> @@ -366,7 +367,7 @@ AC_SUBST(TARGET_LDFLAGS)
>
>  # Set them to their new values for the tests below.
>  CC="$TARGET_CC"
> -CFLAGS="$TARGET_CFLAGS"
> +CFLAGS="$TARGET_CFLAGS -nostdlib"
>  CPPFLAGS="$TARGET_CPPFLAGS"
>  LDFLAGS="$TARGET_LDFLAGS"
>
> diff --git a/include/multiboot2.h b/include/multiboot2.h
> index 0f2b0cf..e8fe425 100644
> --- a/include/multiboot2.h
> +++ b/include/multiboot2.h
> @@ -34,25 +34,31 @@
>
>  #ifndef ASM_FILE
>
> -#include "stdint.h"
> +#ifdef GRUB_SOURCE
> +#include 
> +#else
> +#include 
> +typedef uint32_t grub_uint32_t;
> +typedef uint64_t grub_uint64_t;
> +#define GRUB_TARGET_SIZEOF_VOID_P (__WORDSIZE / 8)
> +#endif
>
> -/* XXX not portable? */
> -#if __WORDSIZE == 64
> -typedef uint64_t multiboot_word;
> +#if GRUB_TARGET_SIZEOF_VOID_P == 8
> +typedef grub_uint64_t multiboot_word;
>  #else
> -typedef uint32_t multiboot_word;
> +typedef grub_uint32_t multiboot_word;
>  #endif
>
>  struct multiboot_header
>  {
> -  uint32_t magic;
> -  uint32_t flags;
> +  grub_uint32_t magic;
> +  grub_uint32_t flags;
>  };
>
>  struct multiboot_tag_header
>  {
> -  uint32_t key;
> -  uint32_t len;
> +  grub_uint32_t key;
> +  grub_uint32_t len;
>  };
>
>  #define MULTIBOOT2_TAG_RESERVED1 0
> diff --git a/loader/i386/pc/multiboot2.c b/loader/i386/pc/multiboot2.c
> index 2c14ee2..25ef150 100644
> --- a/loader/i386/pc/multiboot2.c
> +++ b/loader/i386/pc/multiboot2.c
> @@ -17,7 +17,6 @@
>  *  along with GRUB.  If not, see .
>  */
>
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -25,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  grub_err_t
>  grub_mb2_arch_elf32_hook (Elf32_Phdr *phdr, UNUSED grub_addr_t *addr)
> diff --git a/loader/multiboot2.c b/loader/multiboot2.c
> index fd82828..34e42c1 100644
> --- a/loader/multiboot2.c
> +++ b/loader/multiboot2.c
> @@ -17,7 +17,6 @@
>  *  along with GRUB.  If not, see .
>  */
>
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -28,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  static grub_addr_t entry;
>  extern grub_dl_t my_mod;
> diff --git a/loader/multiboot_loader.c b/loader/multiboot_loader.c
> index 11ba666..654508e 100644
> --- a/loader/multiboot_loader.c
> +++ b/loader/multiboot_loader.c
> @@ -17,7 +17,6 @@
>  *  along with GRUB.  If not, see .
>  */
>
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -29,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  grub_dl_t my_mod;
>
>
>
> ___
> 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: status grub2 port of grub-legasy map command

[Vladimir 'phcoder' Serbinenko]

On Mon, Jun 1, 2009 at 11:45 PM, Vladimir 'phcoder'
Serbinenko wrote:
> 2009/6/1 Javier Martín :
>> El lun, 01-06-2009 a las 11:53 +0200, Vladimir 'phcoder' Serbinenko
>> escribió:
>>> > Hmm... from those docs, and accepting that we ignore TSRs, we need to
>>> > save %ah and %dl at handler entry, then check the saved %ah at exit,
>>> > like the old handler from GRUB Legacy did - by the way, when writing the
>>> > new handler, I asked what that code did and noone was able to tell me ¬¬
>>> I've the check before calling original handler. Let's hope it makes
>>> code more readable.
>> Personally, I don't think the readability gain is so big to offset the
>> code size increase, but this is just a single opinion.
> I personally don't really care how to do it. But for economy of effort
> I prefer to take what I already have :) But if you insist I can change
> it
I found a way to make it smaller. (a trick with jump). See the attached patch.
I also solved the %dl problem (at least partially). I've put biosnum
routine to boot.mod because 3 of 5 loaders need it on pc so I think
boot.mod is better then a separate module. In the same time it doesn't
go to kernel. This move forces to put boot.mod to platform-specific
files but this inflexibility of build system is a subject for another
patch
>> --
>> -- Lazy, Oblivious, Recurrent Disaster -- Habbit
>>
>> ___
>> 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/i386/pc/drivemap.c b/commands/i386/pc/drivemap.c
index 898fb51..97a1936 100644
--- a/commands/i386/pc/drivemap.c
+++ b/commands/i386/pc/drivemap.c
@@ -23,8 +23,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-
+#include 
 
 
 /* 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 
+  && grub_strcmp (dev->disk->dev->name, "biosdisk") == 0)
+{
+  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..ba31a9c 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
+
+postamble:	
+	
+	pushf
+	pop 	%dx
+	mov 	%dx, 8(%bp)
+
+	pop	%bp
+	
+	/* Restore %dx.  */
+	pop 	%dx
+	iret
+
+norestore:
+
+	/* Restore flags.  */
+	popf
+	pushf
+
+	lcall *%cs:INT13H_OFFSET (EXT_C (grub_drivemap_oldhandler))
+
+	push 	%bp
+	mov 	%sp, %bp
+	
+	/* Save %dx.  */
+	mov 	%dx, 2(%bp)
 
+	jmp postamble
+	
 /* Far pointer to the old handler.  Stored as a CS:IP in the style of real-mode
IVT entries (thus PI:SC in mem).  */
 VARIABLE(grub_drivemap_oldhandler)
diff --git a/conf/common.rmk b/conf/common.rmk
index 3e59c3a..b328bc4 100644
--- a/conf/common.rmk
+++ b/conf/common.rmk
@@ -353,19 +353,13 @@ pkglib_MODULES += minicmd.mod extcmd.mod hello.mod handler.mod	\
 	loopback.mod fs

Re: [PATCH] add true and false commands

[Marco Gerards]

Felix Zielcke  writes:

> Am Freitag, den 05.06.2009, 14:26 +0200 schrieb Marco Gerards:
>> Felix Zielcke  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.

Oh, I didn't know minicmd.mod.  Is it useful to have one instead of
a few separate modules?  Space of these smaller modules is not really
a concern to me.

--
Marco



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] add true and false commands

[Felix Zielcke]

Am Freitag, den 05.06.2009, 14:26 +0200 schrieb Marco Gerards:
> Felix Zielcke  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.
-- 
Felix Zielcke
2009-06-05  Felix Zielcke  

* commands/true.c: New file.  Implement the true and false commands.
* conf/common.rmk.c (pkglib_MODULES): Add `true.mod'.
(true_mod_SOURCES): New variable.
(true_mod_CFLAGS): Likewise.
(true_mod_LDFLAGS): Likewise.

diff --git a/commands/true.c b/commands/true.c
index e69de29..16ca315 100644
--- a/commands/true.c
+++ b/commands/true.c
@@ -0,0 +1,56 @@
+/* true.c - true and false commands.  */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 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 .
+ */
+
+#include 
+#include 
+
+static grub_err_t
+grub_cmd_true (struct grub_command *cmd __attribute__ ((unused)),
+  int argc __attribute__ ((unused)),
+  char *argv[] __attribute__ ((unused)))
+{
+  return 0;
+}
+
+static grub_err_t
+grub_cmd_false (struct grub_command *cmd __attribute__ ((unused)),
+   int argc __attribute__ ((unused)),
+   char *argv[] __attribute__ ((unused)))
+{
+  return grub_error (GRUB_ERR_TEST_FAILURE, "false");
+}
+
+static grub_command_t cmd_true, cmd_false;
+
+
+GRUB_MOD_INIT(true)
+{
+  cmd_true =
+grub_register_command ("true", grub_cmd_true,
+  0, "do nothing, successfully");
+  cmd_false =
+grub_register_command ("false", grub_cmd_false,
+  0, "do nothing, unsuccessfully");
+}
+
+GRUB_MOD_FINI(true)
+{
+  grub_unregister_command (cmd_true);
+  grub_unregister_command (cmd_false);
+}
diff --git a/conf/common.rmk b/conf/common.rmk
index ca18c53..48565bf 100644
--- a/conf/common.rmk
+++ b/conf/common.rmk
@@ -344,7 +344,7 @@ pkglib_MODULES += minicmd.mod extcmd.mod hello.mod 
handler.mod  \
terminfo.mod test.mod blocklist.mod hexdump.mod \
read.mod sleep.mod loadenv.mod crc.mod parttool.mod \
pcpart.mod memrw.mod boot.mod normal.mod sh.mod lua.mod \
-   gptsync.mod
+   gptsync.mod true.mod
 
 # For gptsync.mod.
 gptsync_mod_SOURCES = commands/gptsync.c
@@ -476,6 +476,11 @@ memrw_mod_SOURCES = commands/memrw.c
 memrw_mod_CFLAGS = $(COMMON_CFLAGS)
 memrw_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
+# For true.mod
+true_mod_SOURCES = commands/true.c
+true_mod_CFLAGS = $(COMMON_CFLAGS)
+true_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
 # For normal.mod.
 normal_mod_SOURCES = normal/main.c normal/cmdline.c normal/dyncmd.c \
normal/autofs.c normal/handler.c \
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] add true and false commands

[Marco Gerards]

Felix Zielcke  writes:

> Am Freitag, den 05.06.2009, 12:00 +0200 schrieb Marco Gerards:
>> Felix Zielcke  writes:
>> 
>> > Am Donnerstag, den 04.06.2009, 10:21 +0200 schrieb Marco Gerards:
>> >> Felix Zielcke  writes:
>> >> 
>> >> > Am Montag, den 01.06.2009, 16:24 +0200 schrieb Vladimir 'phcoder'
>> >> > Serbinenko:
>> >> >> However convention for
>> >> >> creating false is:
>> >> >>   return grub_error (GRUB_ERR_TEST_FAILURE, "false");
>> >> >> and not
>> >> >>   return 1;
>> >> >
>> >> > Ok changed it. If everyone is fine with placing this in normal/main.c, I
>> >> > commit it.
>> >> 
>> >> Unless it is essential to do so, please do not place it in
>> >> normal/main.c.
>> >
>> > would normal/misc.c be okay or maybe a new file normal/true.c?
>> > I just don't think it's worth to create a new module for these 2 very
>> > little commands.
>> 
>> The problem is with too many little commands, the size of normal.mod
>> grows.  Although the commands are *very* small and I do not strongly
>> object to inclusion in normal.mod, if noone else has any objection.
>
> The binary size of normal.mod would grow about 264 bytes whereas in
> minicmd.mod it would be just 260 bytes.
> But I already forgot that Bean wants to get rid of normal.mod.
>
> 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.

--
Marco



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] add true and false commands

[Felix Zielcke]

Am Freitag, den 05.06.2009, 12:00 +0200 schrieb Marco Gerards:
> Felix Zielcke  writes:
> 
> > Am Donnerstag, den 04.06.2009, 10:21 +0200 schrieb Marco Gerards:
> >> Felix Zielcke  writes:
> >> 
> >> > Am Montag, den 01.06.2009, 16:24 +0200 schrieb Vladimir 'phcoder'
> >> > Serbinenko:
> >> >> However convention for
> >> >> creating false is:
> >> >>   return grub_error (GRUB_ERR_TEST_FAILURE, "false");
> >> >> and not
> >> >>   return 1;
> >> >
> >> > Ok changed it. If everyone is fine with placing this in normal/main.c, I
> >> > commit it.
> >> 
> >> Unless it is essential to do so, please do not place it in
> >> normal/main.c.
> >
> > would normal/misc.c be okay or maybe a new file normal/true.c?
> > I just don't think it's worth to create a new module for these 2 very
> > little commands.
> 
> The problem is with too many little commands, the size of normal.mod
> grows.  Although the commands are *very* small and I do not strongly
> object to inclusion in normal.mod, if noone else has any objection.

The binary size of normal.mod would grow about 264 bytes whereas in
minicmd.mod it would be just 260 bytes.
But I already forgot that Bean wants to get rid of normal.mod.

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?

-- 
Felix Zielcke



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] add true and false commands

[Marco Gerards]

Felix Zielcke  writes:

> Am Donnerstag, den 04.06.2009, 10:21 +0200 schrieb Marco Gerards:
>> Felix Zielcke  writes:
>> 
>> > Am Montag, den 01.06.2009, 16:24 +0200 schrieb Vladimir 'phcoder'
>> > Serbinenko:
>> >> However convention for
>> >> creating false is:
>> >>   return grub_error (GRUB_ERR_TEST_FAILURE, "false");
>> >> and not
>> >>   return 1;
>> >
>> > Ok changed it. If everyone is fine with placing this in normal/main.c, I
>> > commit it.
>> 
>> Unless it is essential to do so, please do not place it in
>> normal/main.c.
>
> would normal/misc.c be okay or maybe a new file normal/true.c?
> I just don't think it's worth to create a new module for these 2 very
> little commands.

The problem is with too many little commands, the size of normal.mod
grows.  Although the commands are *very* small and I do not strongly
object to inclusion in normal.mod, if noone else has any objection.

--
Marco



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: multiboot take partial mmap

[Colin Watson]

On Fri, Jun 05, 2009 at 03:24:09AM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Thu, Jun 4, 2009 at 10:07 PM, Andrey Valyaev 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.

-- 
Colin Watson   [cjwat...@ubuntu.com]


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

please try to remember to update NEWS

[Felix Zielcke]

Hello all,

it would be very nice if you could remember to add a NEWS entry if you
add some fancy new feature which end users would like.
For examples just look in NEWS ;)

Yesterday I added again a few things but probable there's still more
missing which maybe should be added.

-- 
Felix Zielcke



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] add true and false commands

[Felix Zielcke]

Am Donnerstag, den 04.06.2009, 10:21 +0200 schrieb Marco Gerards:
> Felix Zielcke  writes:
> 
> > Am Montag, den 01.06.2009, 16:24 +0200 schrieb Vladimir 'phcoder'
> > Serbinenko:
> >> However convention for
> >> creating false is:
> >>   return grub_error (GRUB_ERR_TEST_FAILURE, "false");
> >> and not
> >>   return 1;
> >
> > Ok changed it. If everyone is fine with placing this in normal/main.c, I
> > commit it.
> 
> Unless it is essential to do so, please do not place it in
> normal/main.c.
> 

would normal/misc.c be okay or maybe a new file normal/true.c?
I just don't think it's worth to create a new module for these 2 very
little commands.
-- 
Felix Zielcke



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel