Re: [PATCH] Fix chainloding + Chainloading into logical partitions
On Sun, Jul 6, 2008 at 5:47 PM, Lucas Gadani [EMAIL PROTECTED] wrote: On Sun, Jul 6, 2008 at 18:41, Robert Millan [EMAIL PROTECTED] wrote: Looks like it increases pc.mod code to store information that is only useful to the chainloader. Is there a reason for not having the chainloader retrieve it? (note that for disk access we have a cache) We would need to duplicate the code that iterates through the logical partitions in the chainloader or we can change pc_partition_map_iterate hook function to also receive grub_pc_partition (we can't use the pc_partition_map_iterate cause the hook function only receives a grub_disk_t and grub_partition_t, but not the grub_pc_partition that's necessary to reconstruct the partition info). What would be the best patch to get accepted into grub? I'm willing to code the patch, but first I'd like to know the best way to get comitted to grub. -- Lucas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fix chainloding + Chainloading into logical partitions
On Thu, Jul 10, 2008 at 10:08 PM, Lucas Gadani [EMAIL PROTECTED] wrote: On Sun, Jul 6, 2008 at 5:47 PM, Lucas Gadani [EMAIL PROTECTED] wrote: On Sun, Jul 6, 2008 at 18:41, Robert Millan [EMAIL PROTECTED] wrote: Looks like it increases pc.mod code to store information that is only useful to the chainloader. Is there a reason for not having the chainloader retrieve it? (note that for disk access we have a cache) We would need to duplicate the code that iterates through the logical partitions in the chainloader or we can change pc_partition_map_iterate hook function to also receive grub_pc_partition (we can't use the pc_partition_map_iterate cause the hook function only receives a grub_disk_t and grub_partition_t, but not the grub_pc_partition that's necessary to reconstruct the partition info). What would be the best patch to get accepted into grub? I'm willing to code the patch, but first I'd like to know the best way to get comitted to grub. Hi, I don't know how many fields of partition table is actually used by syslinux. But from your code, I get the sense that only the start sector is used. If that's the case, there is no need to save the partition entry, we can just set the value in chainloader. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] GRUB Loading message
As per the GRUB Loading kernel discussion (interpreting silence as send a patch). I guess I need to write a ChangeLog entry, is there anything telling me how to do that? I looked at other examples on this list and wasn't sure how to apply them here. Is there anything else I'm missing? I forgot to test that it does anything more than compile, is there some way to test in an emulator (documented somewhere? Maybe QEMU, parted etc. work with a file as a whole set of partitions?) -Isaac Index: grub2patching/boot/i386/pc/diskboot.S === --- grub2patching.orig/boot/i386/pc/diskboot.S 2008-07-10 11:16:18.0 -0400 +++ grub2patching/boot/i386/pc/diskboot.S 2008-07-10 11:17:23.0 -0400 @@ -326,7 +326,7 @@ /* go here when you need to stop the machine hard after an error condition */ stop: jmp stop -notification_string: .string Loading kernel +notification_string: .string Loading notification_step: .string . notification_done: .string \r\n ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GRUB Loading message
Quoting Isaac Dupree [EMAIL PROTECTED]: As per the GRUB Loading kernel discussion (interpreting silence as send a patch). I guess I need to write a ChangeLog entry, is there anything telling me how to do that? I looked at other examples on this list and wasn't sure how to apply them here. Is there anything else I'm missing? I forgot to test that it does anything more than compile, is there some way to test in an emulator (documented somewhere? Maybe QEMU, parted etc. work with a file as a whole set of partitions?) It's already applied (with small l). I should have posted it to the list, sorry. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GRUB Loading message
Pavel Roskin wrote: Quoting Isaac Dupree [EMAIL PROTECTED]: As per the GRUB Loading kernel discussion (interpreting silence as send a patch). I guess I need to write a ChangeLog entry, is there anything telling me how to do that? I looked at other examples on this list and wasn't sure how to apply them here. Is there anything else I'm missing? I forgot to test that it does anything more than compile, is there some way to test in an emulator (documented somewhere? Maybe QEMU, parted etc. work with a file as a whole set of partitions?) It's already applied (with small l). I should have posted it to the list, sorry. Odd, I didn't see it changed in boot/i386/pc/diskboot.S when I do `cvs up`? Or have we switched over to SVN now?(in which case what svn co should I do?) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GRUB Loading message
On Fri, Jul 11, 2008 at 12:01 AM, Isaac Dupree [EMAIL PROTECTED] wrote: Pavel Roskin wrote: Quoting Isaac Dupree [EMAIL PROTECTED]: As per the GRUB Loading kernel discussion (interpreting silence as send a patch). I guess I need to write a ChangeLog entry, is there anything telling me how to do that? I looked at other examples on this list and wasn't sure how to apply them here. Is there anything else I'm missing? I forgot to test that it does anything more than compile, is there some way to test in an emulator (documented somewhere? Maybe QEMU, parted etc. work with a file as a whole set of partitions?) It's already applied (with small l). I should have posted it to the list, sorry. Odd, I didn't see it changed in boot/i386/pc/diskboot.S when I do `cvs up`? Or have we switched over to SVN now?(in which case what svn co should I do?) Hi, It have switched to svn now, cvs is not updated anymore. But there is a small issue, email notification is not working at the moment, you need to run svn update once in a while to discover new commits. Is there similar function in the git mirror ? Perhaps we can use that until svn notification works. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GRUB Loading message
On Fri, 2008-07-11 at 00:31 +0800, Bean wrote: It have switched to svn now, cvs is not updated anymore. Can we turn CVS off? We could remove all files as the first step. But there is a small issue, email notification is not working at the moment, you need to run svn update once in a while to discover new commits. If the admins (Marco and Okuji) cannot turn it on, somebody should talk to the Savannah operators. Is there similar function in the git mirror ? Perhaps we can use that until svn notification works. There is no such function. Somebody could write a cron script that would check the Subversion repository and send messages for new commits. But such things is not my strong side. I'll appreciate if somebody else does it. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GRUB Loading message
Bean wrote: It have switched to svn now, cvs is not updated anymore. like this, then svn co svn://svn.savannah.gnu.org/grub/trunk/grub2/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GRUB Loading message
On Fri, Jul 11, 2008 at 1:29 AM, Pavel Roskin [EMAIL PROTECTED] wrote: There is no such function. Somebody could write a cron script that would check the Subversion repository and send messages for new commits. But such things is not my strong side. I'll appreciate if somebody else does it. Hi, I google it a bit, it seems git can send email notification. There is a script /usr/share/doc/git-core/contrib/hooks/post-receive-email, you can copy it to the .git/hooks/post-receive. You also need to setup a few variables using git-config. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Endianness macros capitalization
Pavel Roskin wrote:
On Wed, 2008-07-09 at 14:50 +0200, Christian Franke wrote:
Result with the test script from my last mail:
Debian gcc 4.1.2-7:
inline (portable)=357, inline (asm)=126, function=104
Cygwin gcc 3.4.4:
inline (portable)=340, inline (asm)=124, function=96
Function call is still better. The only candidate for inline is probably
grub_swap_bytes16().
But we are getting closer!
But probably not close enough in the average case, see below :-)
And if written properly, it could work with any of
the registers that allow access to the lower two bytes (%eax, %ebx,
%ecx and %edx), thus giving more flexibility to the optimizer.
This would require support to access the Rl and Rh parts of eRx for each
R in [a-d]. Something like:
asm (
xchg %0:l,%0:h\n
roll $0x10,%0\n
xchg %0:l,%0:h\n
: =r(_y) : 0(_x) \
);
Do gcc or gas provide a syntax to do this?
Yes. That's %b0 and %h0. Use =q for all registers with upper
halves (%ah-%dh).
Thanks for the info.
I tried this in the same script:
#define grub_swap_bytes32(x) \
({ \
grub_uint32_t _x = (x), _y; \
asm ( \
xchgb %b0,%h0\n \
roll $0x10,%0\n \
xchgb %b0,%h0\n \
: =q(_y) : 0(_x) \
); \
_y; \
})
GCC optimizer does a good job optimizing register use, but function call
is still better:
Debian gcc 4.1.2-7:
inline (portable)=357,asm (%%eax)=126, asm (%0)=107, function=104
Cygwin gcc 3.4.4:
inline (portable)=340, asm (%%eax)=124, asm (%0)=104, function=96
Inline asm is only better is rare cases, e.g. with this test function:
type test(type *x)
{
return func(x[0]) + func(x[1]) + ... + func(x[N]);
}
Result with Cygwin gcc 3.4.4:
N=0: asm=14, function=11
N=1: asm=28, function=32
N=2: asm=40, function=41
N=3: asm=52, function=51
N=4: asm=64, function=61
N=5: asm=76, function=72
To test which files would possibly be affected by any size optimization
of grub_swap_bytes*(), I 've done a test compilation with these macros
replaced by dummies '(x)'. Only the size of following modules changed:
affs.mod
afs.mod
amiga.mod
apple.mod
ata.mod
hfs.mod
hfsplus.mod
iso9660.mod
jpeg.mod
png.mod
sfs.mod
sun.mod
xfs.mod
Remaining modules and kernel.img are identical.
Christian
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Endianness macros capitalization
Quoting Christian Franke [EMAIL PROTECTED]: GCC optimizer does a good job optimizing register use, but function call is still better: Debian gcc 4.1.2-7: inline (portable)=357,asm (%%eax)=126, asm (%0)=107, function=104 Cygwin gcc 3.4.4: inline (portable)=340, asm (%%eax)=124, asm (%0)=104, function=96 Thank you for testing! We could do better with the bswap instruction, but it appeared in 486. I think we still need to support 386. I understand you are counting the function body, so the calling/inlining code is bigger by more than just 3 or 8 bytes. If the code grows, so will the number of the calls or the inline sites. Yet the function size will remain the same. Chances are that if we use 3 rols and allow all general purpose registers, we may save a couple more bytes, because the assembler will still convert rol to xchg when possible, whereas gcc will be able to use non-e*x registers if needed. But I don't want to ask you to spend any more time on it. I think we'll have to go with the function for 32 bit. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ext4 extent support
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. -- Bean Any news? Will it be committed soon? Just saw that there's a commit on e2fsprogs 1.41 wich enables uninit_bg enables for ext4 by default. It would be very nice if grub would support that, too :) huge_file,dir_nlink,extra_isize are enabled now, too but these are ROCOMPAT features so no need to worry Tytso wants to get e2fsprogs 1.41 into lenny [1] Woudn' be that bad if grub would support ext4 on lenny [1] http://lists.debian.org/debian-release/2008/07/msg00120.html ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
