From: "Bean" <[EMAIL PROTECTED]>
Sent: Friday, July 04, 2008 7:59 PM
To: "The development of GRUB 2"
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 and flex_bg,
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 mensa
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 GRUB
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 comman
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
> Th
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 EXT3_
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
From: "JavierMartín" <[EMAIL PROTECTED]>
Sent: Saturday, July 05, 2008 3:25 PM
To: "The development of GRUB 2"
Subject: Re: [PATCH] ext4 extent support
I think flex_bg support is unimplemented right now (at least I didn't
see it anywhere), but it "worked" because it's not being used? Just a
gue
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 s
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 re
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
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?
>
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
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" diff
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
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"
> Subject: Re: [PATCH] ext4 extent support
>
> >I think flex_bg support is unimplemented right now (at least I didn't
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 functionality
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, sin
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 applica
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 standalon
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 GRUB_LE_TO_C
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); \
(g
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 "h
On Sun, 2008-07-06 at 00:54 +0200, Javier Martín wrote:
> 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
>
> #defi
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 n
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 " firs
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.
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"
>> Subject: Re: [PATCH] ext4 extent suppo
31 matches
Mail list logo
