From: Bean [EMAIL PROTECTED]
Sent: Friday, July 04, 2008 7:59 PM
To: The development of GRUB 2 grub-devel@gnu.org
Subject: [PATCH] ext4 extent support
Hi,
This patch add support for extents in ext4.
Thanks for the patch.I just tested it
GRUB now works fine with 31 MB /boot ext4 with extent
Just my two (euro) cents: why are the endianness macros written like
functions? I'm talking about the grub_Xe_to_cpuNN family, which look
like function calls instead of the macros they are. Shouldn't they be
capitalized to GRUB_LE_TO_CPU32 and such?
signature.asc
Description: Esta parte del
El sáb, 05-07-2008 a las 11:39 +0200, Felix Zielcke escribió:
GRUB now works fine with 31 MB /boot ext4 with extent
Wonderful!! Bean, you're awesome!
and flex_bg, though
flex_bg shouldn't make a difference on that small partiton
I think flex_bg support is unimplemented right now (at least I
On my raid1-using system, I get the following error at boot:
error: Found two disks with the number 0?!?
Robert Millan suggested I apply a patch to print out the two disks with
this problem; they are (hd1,2) and (hd3,2).
If I comment out this check then I can boot normally. Robert things
On Sat, Jul 05, 2008 at 10:46:56AM +0800, Bean wrote:
If we move the option analyzer from normal.mod to
kernel, then we can have one unified set of commands.
How much space could this represent?
About the duplicated commands, we can create a module minicmd to
include the most basic command
On Fri, Jul 04, 2008 at 10:41:35PM +0200, Javier Martín wrote:
Wonderful! I was sick of jumping through hoops with cvs diff.
I wasn't even using cvs diff! (you don't want to know what my replacement
dance was) ;-)
I'd suggest making the RW compatible etc notes a bit more ellaborate to
Javier Martín [EMAIL PROTECTED] writes:
Just an updated version of the patch that adds support for device-like
names instead of raw BIOS disk numbers, i.e. this is now supported:
grub drivemap (hd0) (hd1)
In addition to the already supported:
grub drivemap (hd0) 0x81
The effect
Hi Bean,
Bean [EMAIL PROTECTED] writes:
This patch add support for extents in ext4.
This is really great! :D
Can you also provide a changelog entry?
diff --git a/fs/ext2.c b/fs/ext2.c
index 22fd272..3518dcf 100644
--- a/fs/ext2.c
+++ b/fs/ext2.c
@@ -86,6 +86,8 @@
#define
Robert Millan wrote:
About the duplicated commands, we can create a module minicmd to
include the most basic command
Then we can't have a rescue shell before heap is initialised and minicmd
is loaded. Should we be concerned about this?
What would one use that rescue shell for?
On Sat, Jul 5, 2008 at 7:01 PM, Marco Gerards [EMAIL PROTECTED] wrote:
+ grub_printf (HH\n);
Whoops? ;-)
+ return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,
+ ext2fs doesn't support extents);
Why the error? I thought you have added extent support? Doesn't
Stefan Reinauer wrote:
Robert Millan wrote:
About the duplicated commands, we can create a module minicmd to
include the most basic command
Then we can't have a rescue shell before heap is initialised and minicmd
is loaded. Should we be concerned about this?
What would one use that
On Sat, Jul 5, 2008 at 8:15 PM, Robert Millan [EMAIL PROTECTED] wrote:
On Sat, Jul 05, 2008 at 10:46:56AM +0800, Bean wrote:
If we move the option analyzer from normal.mod to
kernel, then we can have one unified set of commands.
How much space could this represent?
It won't take much, the
On Sun, Jul 6, 2008 at 1:32 AM, Bean [EMAIL PROTECTED] wrote:
About the duplicated commands, we can create a module minicmd to
include the most basic command
Then we can't have a rescue shell before heap is initialised and minicmd
is loaded. Should we be concerned about this?
The rescue
Vesa Jääskeläinen wrote:
Stefan Reinauer wrote:
Robert Millan wrote:
About the duplicated commands, we can create a module minicmd to
include the most basic command
Then we can't have a rescue shell before heap is initialised and
minicmd
is loaded. Should we be concerned about this?
Stefan Reinauer wrote:
Vesa Jääskeläinen wrote:
Idea of the rescue shell is load other modules in case grub itself
cannot find them. It provides thin layer of tools so user is able to
find them.
Personally I would like to keep this functionality in core.img.
So, how is the rescue shell
Vesa Jääskeläinen wrote:
Stefan Reinauer wrote:
Vesa Jääskeläinen wrote:
Idea of the rescue shell is load other modules in case grub itself
cannot find them. It provides thin layer of tools so user is able to
find them.
Personally I would like to keep this functionality in core.img.
So,
El sáb, 05-07-2008 a las 19:15 +0200, Felix Zielcke escribió:
From: JavierMartín [EMAIL PROTECTED]
Sent: Saturday, July 05, 2008 3:25 PM
To: The development of GRUB 2 grub-devel@gnu.org
Subject: Re: [PATCH] ext4 extent support
I think flex_bg support is unimplemented right now (at least I
Stefan Reinauer wrote:
Vesa Jääskeläinen wrote:
Stefan Reinauer wrote:
Vesa Jääskeläinen wrote:
Idea of the rescue shell is load other modules in case grub itself
cannot find them. It provides thin layer of tools so user is able to
find them.
Personally I would like to keep this
El sáb, 05-07-2008 a las 14:07 +0200, Robert Millan escribió:
However, adding new strings is expensive, since they tend to take size more
easily than code. I would be careful about that.
I checked the space requirements, and seemingly there was a bit of space
available in the .rodata zone,
On Sun, Jul 6, 2008 at 2:10 AM, Vesa Jääskeläinen [EMAIL PROTECTED] wrote:
It has anything what core provides. If by this you get core smaller then I
am all for it. If it makes it larger then I would propose to find free space
from somewhere else. Core.img just have to be standalone application
Bean wrote:
On Sun, Jul 6, 2008 at 2:10 AM, Vesa Jääskeläinen [EMAIL PROTECTED] wrote:
It has anything what core provides. If by this you get core smaller then I
am all for it. If it makes it larger then I would propose to find free space
from somewhere else. Core.img just have to be standalone
On Sat, 2008-07-05 at 15:27 +0200, Javier Martín wrote:
Just my two (euro) cents: why are the endianness macros written like
functions? I'm talking about the grub_Xe_to_cpuNN family, which look
like function calls instead of the macros they are. Shouldn't they be
capitalized to
El sáb, 05-07-2008 a las 17:30 -0400, Pavel Roskin escribió:
They probably should be functions. We may want to sparse annotate GRUB
one day, and then inline functions in the only way to go.
Hmm... you mean changing this
#define grub_swap_bytes16(x)\
({ \
grub_uint16_t _x = (x); \
Bean wrote:
Hi,
Perhaps you can also try the binary version at:
http://grub4dos.sourceforge.net/grub2/grub.efi.1
A friend of mine have tested in in 32-bit EFI firmware, there is no
problem for him.
It confuses me! I could boot it from refit as EFI. Then it claimed to
be GRUB 0.97. The
I thought I remembered somewhere a discussion how the message
GRUB Loading kernel
is confusing, because it doesn't say what kernel it's loading, and grub
loads lots of kernels (this message means that the kernel is a core
part of GRUB, and the subject GRUB the message mentions is different:
On Sat, 2008-07-05 at 19:24 -0400, Isaac Dupree wrote:
. Although, looking at the files, boot/i386/pc/boot.S outputs GRUB
and boot/i386/pc/diskboot.S outputs Loading kernel, so the parts
actually mean different things: maybe it's important that it prints
GRUB first in case it never
Pavel Roskin wrote:
On Sat, 2008-07-05 at 19:24 -0400, Isaac Dupree wrote:
. Although, looking at the files, boot/i386/pc/boot.S outputs GRUB
and boot/i386/pc/diskboot.S outputs Loading kernel, so the parts
actually mean different things: maybe it's important that it prints
GRUB first in
On Sun, Jul 6, 2008 at 7:02 AM, Isaac Dupree
[EMAIL PROTECTED] wrote:
Bean wrote:
Hi,
Perhaps you can also try the binary version at:
http://grub4dos.sourceforge.net/grub2/grub.efi.1
A friend of mine have tested in in 32-bit EFI firmware, there is no
problem for him.
It confuses me! I
On Sun, Jul 6, 2008 at 2:09 AM, Javier Martín [EMAIL PROTECTED] wrote:
El sáb, 05-07-2008 a las 19:15 +0200, Felix Zielcke escribió:
From: JavierMartín [EMAIL PROTECTED]
Sent: Saturday, July 05, 2008 3:25 PM
To: The development of GRUB 2 grub-devel@gnu.org
Subject: Re: [PATCH] ext4 extent
29 matches
Mail list logo
