Re: [RFC]swapfso and "ioctl" function for filesystems

[Robert Millan]

On Thu, Sep 04, 2008 at 11:27:20PM +0200, phcoder wrote:
> > 
> > Could this be made more transparent?  For example, with a variable.
> > 
> Here perhaps it could be. But in other usage cases like putting the dos
> boot files into the right place or doing swapfso it couldn't.

We intentionally don't support filesystem writing.  This was discussed before,
I think.

> > Also, I'm worried that this occupies core image size for non-critical
> > functionality.
> > 
> If filesystem module doesn't use this feature it just adds a zero
> pointer to grub_fs structure.

Yes, but what if it does?

> may be implemented in an extra module
> (like ntfscomp) or there could be 2 modules for the same filesystem:
> basic and advanced one.

2 modules for the same filesystem can lead to trouble;  I don't think GRUB
can handle this situation properly (for example, if you need ext2.mod to
access $prefix, how to you replace it with the new module, which needs to be
loaded precisely from $prefix?).

An extra module would be saner, IMO.

-- 
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] Boot parameters and geometrical stability

[Robert Millan]

On Thu, Sep 04, 2008 at 11:40:32PM +0200, phcoder wrote:
> Robert Millan wrote:
> > On Wed, Sep 03, 2008 at 08:49:14PM +0300, Vesa Jääskeläinen wrote:
> >> Possibilites are there, but basically they are limited to something like:
> >>
> >> (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)
> > 
> > I think this is overkill, and doesn't really address the root of the 
> > problem.
> > 
> > The real security problem here is whether the executable code you're 
> > loading is
> > trusted, NOT where you load the code from.
> If the code is loaded from the same place as we do then we can trust it
> (if attacker could modify the code, he could also modify us)

Right.  I was assuming you mean when code is loaded from different places.
Having untrusted code perform the verification of other untrusted code is
useless, of course.

-- 
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] Boot parameters and geometrical stability

[Robert Millan]

On Thu, Sep 04, 2008 at 11:37:43PM +0200, phcoder wrote:
> Robert Millan wrote:
> > On Wed, Sep 03, 2008 at 02:31:10PM +0200, phcoder wrote:
> >>> I assume you talk about GRUB loading itself;  what kind of information 
> >>> would
> >>> you pass from one GRUB to the other?
> >> Boot device,
> > 
> > Multiboot already handles that (although it's not reliable; I don't
> > think this feature should be used anyway).
> > 
> Feature in multiboot is hmm..: it gives bios device and grub supports
> also other devices.

Yes.  Besides, it's only an integer, which isn't able to reliably identify
a device.  That's why I don't think this feature should be used.

> > Which parameters do you have in mind?
> > 
> I thought of it more like about instruction like: boot from strange
> place or enter debug mode in early stage.

You don't need additional parameters for that.  Since both loader and loadee
can take user input, user can tell the loadee to enter debug mode instead of
the loader (press 'c', then set debug=something, etc).

> > Doesn't PXE already handle this?
> > 
> I'm not really familiar with it. Does it support multiple servers.

Neither am I.  I think we should have a clear idea on what our requirements
for PXE are before discussing if we need to use boot parameters for it.

> But still for me this feature is just an idea. I'm still not
> persuaded myself whether it's needed.

Maybe it's a good idea, or maybe it's not useful for anything.  I think first
of all we should exactly know what it is needed for.  IMHO, we should be
careful about adding interfaces just for the sake of having them.

-- 
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: Multiple partition maps

[Robert Millan]

On Thu, Sep 04, 2008 at 11:49:21PM +0200, phcoder wrote:
> Robert Millan wrote:
> > On Wed, Sep 03, 2008 at 08:08:50PM +0200, phcoder wrote:
> >> Hello. I was looking at the grub code and seen that if a disk has
> >> multiple partition tables (e.g. macintel with bootcamp) then only first
> >> one will be detected. In some cases it can lead to unreachable
> >> partitions if for some reason partition is present only in one table.
> >> Does anyone has an idea how theese cases may be treated compactly and
> >> efficiently?
> > 
> > Strictly speaking, GPT+MSDOS hybrid tables are a violation of the GPT
> > specification.  It's not clear what would be the "correct" way of handling
> > them.
> > 
> > Since we're not a legacy program, I suppose the sane thing to do would be
> > to abort MSDOS probing if a protective DOS partition (0xee) is found, and
> > then only GPT will be used.
> 
> We're not a legacy application but some OS and partition tools are and
> we have to work with them. I think just some maintenance tools included
> in GRUB should be enough. I'll write them soon. (perhaps even tomorrow)

I don't understand.  Which kind of maintenance do you mean?  GRUB isn't
designed to modify partition maps, only read them.  Perhaps what you want
is more related to Parted?

> > Isn't this what GRUB does already?  I thought it would be...
> > 
> It does. But I don't know if there are other cases similar to this one.

There's also grub-setup.  On an hybrid map the only option is to follow the
GPT install path and search for a BIOS boot partition (or otherwise use
blocklists).  Does it DTRT already?

I don't know of any other similar situation.

-- 
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

[PATCH] Move cpuid.mod to conf/i386.rmk (Re: RFC: conf/i386.rmk)

[Robert Millan]

On Tue, Aug 05, 2008 at 05:08:29PM -0400, Pavel Roskin wrote:
> On Tue, 2008-08-05 at 22:07 +0200, Robert Millan wrote:
> > On Tue, Aug 05, 2008 at 12:49:46PM -0400, Pavel Roskin wrote:
> > > On Tue, 2008-08-05 at 09:58 +0300, Vesa Jääskeläinen wrote:
> > > 
> > > > > I tried moving more stuff to common.rmk many times but gave up every
> > > > > time.  One of the reasons is that the sparc64 support is very
> > > > > out-of-date and doesn't use common.rmk at all.  I cannot even test it
> > > > > (well, I haven't tries hard).
> > > > 
> > > > If sparc64 support is out of date and the maintainer is nowhere to be 
> > > > seen then I think you can put that support to graveyard until someone 
> > > > comes up to update it. Putting all common stuff to every platform to 
> > > > common.rmk is a good way and the only way (in my opinion) to go forward.
> > > 
> > > OK, then there is an issue that it doesn't work if done naively.
> > 
> > What is the problem exactly?
> 
> Take all text in conf/i386-pc.rmk from "For grub-emu" to "Scripts" and
> move it to the end of conf/common.rmk.  Run autogen.sh, configure
> --enable-grub-emu and make.  You'll get:
> 
> make: *** No rule to make target `grub-emu', needed by `all-local'.
> Stop.

Okay then.  Since it appears this kind of changes are delicate, I propose
doing them granularly.

Here's my first patch, that moves cpuid.mod and sets the base for moving more
stuff later (I've tested the resulting cpuid.mod is built correctly).

-- 
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."
2008-09-05  Robert Millan  <[EMAIL PROTECTED]>

	* conf/i386.rmk: New file.  Provides declaration for building
	`cpuid.mod'.
	* conf/i386-pc.rmk (pkglib_MODULES): Remove `cpuid.mod'.
	(cpuid_mod_SOURCES, cpuid_mod_CFLAGS, cpuid_mod_LDFLAGS): Remove
	variables.
	Include `conf/i386.mk'.
	* conf/i386-efi.rmk: Likewise.
	* conf/x86_64-efi.rmk: Likewise.
	* conf/i386-coreboot.rmk: Likewise.
	* conf/i386-ieee1275.rmk: Likewise.

Index: conf/i386.rmk
===
--- conf/i386.rmk	(revision 0)
+++ conf/i386.rmk	(revision 0)
@@ -0,0 +1,8 @@
+# -*- makefile -*-
+
+pkglib_MODULES += cpuid.mod
+
+# For cpuid.mod.
+cpuid_mod_SOURCES = commands/i386/cpuid.c
+cpuid_mod_CFLAGS = $(COMMON_CFLAGS)
+cpuid_mod_LDFLAGS = $(COMMON_LDFLAGS)
Index: conf/i386-pc.rmk
===
--- conf/i386-pc.rmk	(revision 1851)
+++ conf/i386-pc.rmk	(working copy)
@@ -163,7 +163,7 @@
 pkglib_MODULES = biosdisk.mod _chain.mod _linux.mod linux.mod normal.mod \
 	_multiboot.mod chain.mod multiboot.mod reboot.mod halt.mod	\
 	vbe.mod vbetest.mod vbeinfo.mod video.mod gfxterm.mod \
-	videotest.mod play.mod bitmap.mod tga.mod cpuid.mod serial.mod	\
+	videotest.mod play.mod bitmap.mod tga.mod serial.mod	\
 	ata.mod vga.mod memdisk.mod jpeg.mod png.mod pci.mod lspci.mod \
 	aout.mod _bsd.mod bsd.mod pxe.mod pxecmd.mod datetime.mod date.mod \
 	datehook.mod
@@ -278,11 +278,6 @@
 tga_mod_CFLAGS = $(COMMON_CFLAGS)
 tga_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
-# For cpuid.mod.
-cpuid_mod_SOURCES = commands/i386/cpuid.c
-cpuid_mod_CFLAGS = $(COMMON_CFLAGS)
-cpuid_mod_LDFLAGS = $(COMMON_LDFLAGS)
-
 # For ata.mod.
 ata_mod_SOURCES = disk/ata.c
 ata_mod_CFLAGS = $(COMMON_CFLAGS)
@@ -358,4 +353,5 @@
 datehook_mod_CFLAGS = $(COMMON_CFLAGS)
 datehook_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
+include $(srcdir)/conf/i386.mk
 include $(srcdir)/conf/common.mk
Index: conf/i386-efi.rmk
===
--- conf/i386-efi.rmk	(revision 1851)
+++ conf/i386-efi.rmk	(working copy)
@@ -76,7 +76,7 @@
 
 # Modules.
 pkglib_MODULES = kernel.mod normal.mod _chain.mod chain.mod appleldr.mod \
-	_linux.mod linux.mod cpuid.mod halt.mod reboot.mod pci.mod lspci.mod \
+	_linux.mod linux.mod halt.mod reboot.mod pci.mod lspci.mod \
 	datetime.mod date.mod datehook.mod
 
 # For kernel.mod.
@@ -144,11 +144,6 @@
 linux_mod_CFLAGS = $(COMMON_CFLAGS)
 linux_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
-# For cpuid.mod.
-cpuid_mod_SOURCES = commands/i386/cpuid.c
-cpuid_mod_CFLAGS = $(COMMON_CFLAGS)
-cpuid_mod_LDFLAGS = $(COMMON_LDFLAGS)
-
 # For halt.mod.
 halt_mod_SOURCES = commands/halt.c
 halt_mod_CFLAGS = $(COMMON_CFLAGS)
@@ -184,4 +179,5 @@
 datehook_mod_CFLAGS = $(COMMON_CFLAGS)
 datehook_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
+include $(srcdir)/conf/i386.mk
 include $(srcdir)/conf/common.mk
Index: conf/x86_64-efi.rmk
===
--- conf/x86_64-efi.rmk	(revision 1851)
+++ conf/x86_64-efi.rmk	(working copy)
@@ -78,7 +78,7 @@
 
 # Modules.
 pkglib_MODULES = kernel.mod normal.mod _chain.mod chain.mod appleldr.mod \
-	cpuid.mod halt.mod reboot.mod _linux.mod linux.mod pci.mod lspci.mod \
+	halt.mod reboot.mod _li

Re: When the 'Fancy Menu' branch will be availble on the main thread?

[Vesa Jääskeläinen]

y.volta wrote:
> hi, all:
> 
> Collin has submit the 'Fancy Menu', when it will be available on the main 
> svn thread? 

When it gets reviewed and merged. I have been slowly adapting some of
the patches to my local devel tree so they can get committed. However I
need to make sure they are architectually correct and that takes time.
If changes are more radical then we wait that we have improved patches.

> And i want to make sure: 
> 
> - the fancy menu will support two bytes language?

Unicode support is built in. Other than English script (eg. character
positioning) is not supported however. It should be good enough for most
of the languages on world (eg. Japanese, European, US), but is not
working properly on more challenging ones like Hebrew and Islam

> 
> - the vbe engine support non linear frame buffer modes? 
> 
> i read the vbe.c line 445: 
> 
> /* We support only linear frame buffer modes.  */, 
> 
> if so, the graphic menu will not be available for some hardware or 
> screen resolution.

I have no plans to write support for banked modes.

> - grub video uses double buffering, if this is available. if not, the bliting 
> will be very slow. so,  how about using clip-box to improve it? backup area 
> -> draw contents -> recover area -> draw new contents. ( by using this, there 
> is no need to switch a whole screen. ^_^ )

There is similar feature in gfxterm. We will first get this merged and
then we worry about performance.

> - can the VBE engine support 16 bits (5:6:5) mode?

Yes. Thou, there are no accelerated functions for it, so it will be slow.

> i've not familiar with grub2's video system, so, please help me out. Thanks!

http://grub.enbug.org/VideoSubsystem


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

Re: [PATCH] Case insensitive filename for NTFS

[Bean]

On Sat, Aug 30, 2008 at 8:47 PM, Robert Millan <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 30, 2008 at 03:07:21AM +0800, Bean wrote:
>> Hi,
>>
>> This patch allow case insensitive filename in Win32 and DOS namespace.
>> Names in POSIX namespace would still be case sensitive. It also remove
>> names in the DOS namespace, as they will reappear in Win32 namespace.
>
> Nice work :-)
>
>> --- a/fs/fshelp.c
>> +++ b/fs/fshelp.c
>> @@ -80,7 +80,13 @@ grub_fshelp_find_file (const char *path, 
>> grub_fshelp_node_t rootnode,
>>   enum grub_fshelp_filetype filetype,
>>   grub_fshelp_node_t node)
>>   {
>> -   if (type == GRUB_FSHELP_UNKNOWN || grub_strcmp (name, filename))
>> +  int case_insensitive = (filetype & GRUB_FSHELP_CASE_INSENSITIVE);
>> +
>> +  filetype &= ~GRUB_FSHELP_CASE_INSENSITIVE;
>> +   if (filetype == GRUB_FSHELP_UNKNOWN ||
>> +  (grub_strcmp (name, filename) &&
>> +   (! case_insensitive ||
>> +grub_strncasecmp (name, filename, LONG_MAX
>
> Since `case_insensitive' is only used once, maybe we could skip this
> variable?

Committed.

-- 
Bean


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

[PATCH] Move kern/loader.c to boot.mod and add preboot_support (was Re: Sendkey patch)

[phcoder]

Hello. As I said in another email there is no need for it. I send a
patch for it.
Vladimir 'phcoder' Serbinenko
Javier Martín wrote:
> El mié, 03-09-2008 a las 20:53 +0300, Vesa Jääskeläinen escribió:
>> phcoder wrote:
>>> Hello. In this case we can transfer the whole functionality located in
>>> kern/loader.c to a dedicated module boot.mod. This module will also
>>> register "boot" command. In this way the encapsulation won't be broken
>>> and kernel will become even smaller.
>> Remember that realmode code needs to reside below < 1 MiB. That is the
>> reason realmode code is embedded in kernel. In there you only see jumps
>> to RM and back to PM.
> We could use the relocator functionality that was once discussed here (I
> don't know if it was finally committed) so that modules could declare
> "bundles" of code+data to be deployed to RM area. Or make sure every
> single instruction in there uses 32-bit addressing, together with
> artificial EIP-relativization of addresses like in drivemap_int13.S
> 
> -Habbit
> 
> 
> 
> 
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Index: conf/common.rmk
===
--- conf/common.rmk	(revision 1845)
+++ conf/common.rmk	(working copy)
@@ -311,7 +311,7 @@
 scsi_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
 # Commands.
-pkglib_MODULES += hello.mod boot.mod terminal.mod ls.mod	\
+pkglib_MODULES += hello.mod _boot.mod boot.mod terminal.mod ls.mod	\
 	cmp.mod cat.mod help.mod font.mod search.mod		\
 	loopback.mod fs_uuid.mod configfile.mod echo.mod	\
 	terminfo.mod test.mod blocklist.mod hexdump.mod		\
@@ -322,8 +322,13 @@
 hello_mod_CFLAGS = $(COMMON_CFLAGS)
 hello_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
+# For _boot.mod.
+_boot_mod_SOURCES = commands/boot.c
+_boot_mod_CFLAGS = $(COMMON_CFLAGS)
+_boot_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
 # For boot.mod.
-boot_mod_SOURCES = commands/boot.c
+boot_mod_SOURCES = commands/boot_normal.c
 boot_mod_CFLAGS = $(COMMON_CFLAGS)
 boot_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
Index: conf/i386-pc.rmk
===
--- conf/i386-pc.rmk	(revision 1845)
+++ conf/i386-pc.rmk	(working copy)
@@ -41,7 +41,7 @@
 # For kernel.img.
 kernel_img_SOURCES = kern/i386/pc/startup.S kern/main.c kern/device.c \
 	kern/disk.c kern/dl.c kern/file.c kern/fs.c kern/err.c \
-	kern/misc.c kern/mm.c kern/loader.c kern/rescue.c kern/term.c \
+	kern/misc.c kern/mm.c kern/rescue.c kern/term.c \
 	kern/time.c \
 	kern/i386/dl.c kern/i386/pc/init.c kern/i386/pc/mmap.c \
 	kern/parser.c kern/partition.c \
@@ -113,11 +113,11 @@
 
 # For grub-emu.
 util/grub-emu.c_DEPENDENCIES = grub_emu_init.h
-grub_emu_SOURCES = commands/boot.c commands/cat.c commands/cmp.c	\
+grub_emu_SOURCES = commands/boot.c commands/boot_normal.c commands/cat.c commands/cmp.c	\
 	commands/configfile.c commands/echo.c commands/help.c		\
 	commands/terminal.c commands/ls.c commands/test.c 		\
 	commands/search.c commands/blocklist.c commands/hexdump.c	\
-	lib/hexdump.c commands/i386/pc/halt.c commands/reboot.c		\
+	lib/hexdump.c commands/i386/pc/halt.c  commands/reboot.c		\
 	commands/i386/cpuid.c		\
 	disk/host.c disk/loopback.c	\
 	fs/fshelp.c 	\
@@ -126,7 +126,7 @@
 	kern/device.c kern/disk.c kern/dl.c kern/elf.c kern/env.c	\
 	kern/err.c			\
 	normal/execute.c kern/file.c kern/fs.c normal/lexer.c 		\
-	kern/loader.c kern/main.c kern/misc.c kern/parser.c		\
+	kern/main.c kern/misc.c kern/parser.c		\
 	grub_script.tab.c kern/partition.c kern/rescue.c kern/term.c	\
 	normal/arg.c normal/cmdline.c normal/command.c normal/function.c\
 	normal/completion.c normal/main.c normal/color.c		\
Index: kern/loader.c
===
--- kern/loader.c	(revision 1845)
+++ kern/loader.c	(working copy)
@@ -1,75 +0,0 @@
-/*
- *  GRUB  --  GRand Unified Bootloader
- *  Copyright (C) 2002,2003,2004,2006,2007  Free Software Foundation, Inc.
- *
- *  GRUB is free software: you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation, either version 3 of the License, or
- *  (at your option) any later version.
- *
- *  GRUB is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with GRUB.  If not, see .
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-static grub_err_t (*grub_loader_boot_func) (void);
-static grub_err_t (*grub_loader_unload_func) (void);
-static int grub_loader_noreturn;
-
-static int grub_loader_l

Re: [PATCH] Move kern/loader.c to boot.mod and add preboot_support (was Re: Sendkey patch)

[Javier Martín]

El vie, 05-09-2008 a las 18:13 +0200, phcoder escribió:
> Hello. As I said in another email there is no need for it. I send a
> patch for it.
Well, I won't deny the patch is clever and looks good (I haven't tested
it yet). However, taking the generic "boot" command out of kernel and
leaving the several loader-specific assembly routines (which would be
the parts needing relocation) there is as elegant as vogon poetry.
However, if there is no opposition and your patch works fine - I'm about
to test it right now - we can first commit it (thus making core.img
smaller) and then work on getting the loader asm routines out of kernel.

-Habbit

> Vladimir 'phcoder' Serbinenko
> Javier Martín wrote:
> > El mié, 03-09-2008 a las 20:53 +0300, Vesa Jääskeläinen escribió:
> >> phcoder wrote:
> >>> Hello. In this case we can transfer the whole functionality located in
> >>> kern/loader.c to a dedicated module boot.mod. This module will also
> >>> register "boot" command. In this way the encapsulation won't be broken
> >>> and kernel will become even smaller.
> >> Remember that realmode code needs to reside below < 1 MiB. That is the
> >> reason realmode code is embedded in kernel. In there you only see jumps
> >> to RM and back to PM.
> > We could use the relocator functionality that was once discussed here (I
> > don't know if it was finally committed) so that modules could declare
> > "bundles" of code+data to be deployed to RM area. Or make sure every
> > single instruction in there uses 32-bit addressing, together with
> > artificial EIP-relativization of addresses like in drivemap_int13.S
> > 
> > -Habbit
> > 
> > 
> > 
> > 
> > ___
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/grub-devel
> 
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


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

Re: [PATCH] Warning if grub.cfg not found

[Carles Pina i Estany]

Hi,

On Aug/30/2008, Robert Millan wrote:
> 
> Hi
> 
> On Sat, Aug 23, 2008 at 04:43:14PM +0200, Carles Pina i Estany wrote:
> > Index: normal/cmdline.c
> > ===
> > --- normal/cmdline.c(revision 1826)
> > +++ normal/cmdline.c(working copy)
> > @@ -137,12 +137,17 @@ grub_cmdline_run (int nested)
> >  {
> >grub_normal_init_page ();
> >grub_setcursor (1);
> > +
> > +  if ( nested == -1 )
> 
> nested was intended to be a "boolean";  this changes its meaning, so the name
> becomes confusing.  I think there's no need to reuse the variable in this part
> of GRUB, and it'd be fine to add a new one IMO.  However ...

Ok, I will change in this way that you suggest. Thanks

> > + grub_printf ("\n\
> > + WARNING: GNU GRUB couldn't open /boot/grub/grub.cfg\n\
> > + Falling back to GNU GRUB Command Line\n\n");
> 
> ... this looks like something that belongs whereever the decision to fall
> back is taken.  Then once the problem is handled there, you don't need to
> tell the lower layer whether to print a message or not.

I think that you mean that this message should be showed before it goes
to command line layer? But i think that the command line layer cleans
the screen, so anyway have to know something (or change and avoid
cleaning the screen).
Anyway, I will check it more deep next days.

> 
> Also, I think there are two separate cases:
> 
>   - grub.cfg is there but can't be opened (we need to tell the user about
> _why_ via grub_print_error()).
>   - grub.cfg is simply not there (perhaps the user intended that).
> 
> and the messages should be somewhat different for each one.

Ok, I understand this part

I sent this patch on 23th August, you replied on 30th August and me
again on 5th September. I think that until mid of next week I will a bit
too busy to do it, but I haven't forgot :-)

Thanks for the suggestions,

-- 
Carles Pina i EstanyGPG id: 0x17756391
http://pinux.info


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

Re: [PATCH] Correcting GRUB_CONSOLE_KEY_NPAGE/PPAGE

[Carles Pina i Estany]

Hi,

On Aug/30/2008, Robert Millan wrote:
> On Sun, Aug 24, 2008 at 04:29:44PM +0200, Carles Pina i Estany wrote:
> > 
> > Hi,
> > 
> > I was just thinking now...
> > 
> > On Aug/24/2008, Carles Pina i Estany wrote:
> > 
> > >   * include/grub/powerpc/ieee1275/console.h (GRUB_TERM_NPAGE):
> > >   Changed to 0x5100.
> > >   (GRUB_TERM_PPAGE): Changed to 0x4900.
> > > 
> > >   * include/grub/sparc64/ieee1275/console.h: Likewise.
> > > 
> > >   * include/grub/i386/pc/console.h: Likewise.
> > > 
> > >   * include/grub/efi/console.h: Likewise.
> > 
> > I was just thinking... is there any reason that we have the same macros
> > in 4 different files?
> 
> This would need to be checked carefully, but a quick peek at
> GRUB_CONSOLE_KEY_LEFT:
> 
> ./kern/i386/pc/startup.S:   .word   GRUB_CONSOLE_KEY_LEFT, GRUB_TERM_LEFT
> ./include/grub/i386/pc/console.h:#define GRUB_CONSOLE_KEY_LEFT  0x4B00
> ./include/grub/efi/console.h:#define GRUB_CONSOLE_KEY_LEFT  0x4B00
> ./include/grub/powerpc/ieee1275/console.h:#define GRUB_CONSOLE_KEY_LEFT   
>   0x4B00
> ./include/grub/sparc64/ieee1275/console.h:#define GRUB_CONSOLE_KEY_LEFT   
>   0x4B00
> 
> seems to indicate these macros are part of the BIOS console interface,
> and therefore only used on i386-pc.
> 
> If you can confirm this, I'd recommend just removing them from the other
> console.h files.

I will also check it and confirm (or not confirm). I will do it on next
days.

-- 
Carles Pina i EstanyGPG id: 0x17756391
http://pinux.info


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

Re: [PATCH] iso9660 UUID support by using the creation date/time

[Felix Zielcke]

Am Sonntag, den 31.08.2008, 20:55 +0200 schrieb Felix Zielcke:

> Args, I'm blind :(
> I copied the function from fs/ntfs.c and there it says `grub_malloc 16 + 
> sizeof (\0)'
> With "" it's useless so .5 attached so it doestn't get lost :)

Bean did only the joliet support and he already said it looks okay.
But Marco I'd like to have your comment because you initially coded the
iso9660 support :)




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

[RFC] general-usage real-mode loader

[phcoder]

Hello. A long time ago I written a C+asm code which loads any given code
at any real-mode location, then puts machine in correct state and then
launches the kernel. I can modify this code to suit GRUB2. Then loading
realmode kernel would work like this:
1) copy helper asm to last kb of lower memory
2) jump to the helper
3) helper copies from upper memory the kernel
4) turn A10 bug back on if necessary
5) go to RM
6) prepare registers
7) jump to the kernel

This protocol is very flexible and as such could be used by all loaders
which load kernel in realmode or even in PM (skip step 5, do steps 6-7
in 32-bit mode) except for changing page tables. Such a helper can be
easily implemented as module and so help us removing asm-parts of
loaders from the kernel. If I recieve greenlight for it, I implement it.
Vladimir 'phcoder' Serbinenko


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

Re: [RFC] general-usage real-mode loader

[phcoder]

BTW. This helper would allow easy addition of many different kernels
(freedos, haiku, ntldr, ...)
Vladimir 'phcoder' Serbinenko
phcoder wrote:
> Hello. A long time ago I written a C+asm code which loads any given code
> at any real-mode location, then puts machine in correct state and then
> launches the kernel. I can modify this code to suit GRUB2. Then loading
> realmode kernel would work like this:
> 1) copy helper asm to last kb of lower memory
> 2) jump to the helper
> 3) helper copies from upper memory the kernel
> 4) turn A10 bug back on if necessary
> 5) go to RM
> 6) prepare registers
> 7) jump to the kernel
> 
> This protocol is very flexible and as such could be used by all loaders
> which load kernel in realmode or even in PM (skip step 5, do steps 6-7
> in 32-bit mode) except for changing page tables. Such a helper can be
> easily implemented as module and so help us removing asm-parts of
> loaders from the kernel. If I recieve greenlight for it, I implement it.
> Vladimir 'phcoder' Serbinenko



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