On Mon, Jul 21, 2008 at 4:51 AM, Christian Franke
[EMAIL PROTECTED] wrote:
This adds Cygwin support to kernel sources. It handles the issues introduced
by PE-ELF conversion and adds support for HAVE_ASM_USCORE.
Christian
2007-07-20 Christian Franke [EMAIL PROTECTED]
*
On Mon, Jul 21, 2008 at 3:02 PM, Bean [EMAIL PROTECTED] wrote:
On Mon, Jul 21, 2008 at 4:51 AM, Christian Franke
[EMAIL PROTECTED] wrote:
This adds Cygwin support to kernel sources. It handles the issues introduced
by PE-ELF conversion and adds support for HAVE_ASM_USCORE.
Christian
Le dimanche 20 juillet 2008 à 17:06 +0200, Javier Martín a écrit :
Hi,
This should have been fixed by the transition to LZMA as the compression
algorithm for PC - core.img should now be under 32K and embeddable in
the 32256 bytes available before the first MBR partition.
As I stated earlier
On Monday 21 July 2008 01:49:52 Simon Peter wrote:
I'm still interested in getting strong crypto into grub mainline and
while it's still not in, I just saw you guys proposed this as a project
for Google's summer of code. Are you going to point students at the
code I already produced? Would be
Bean wrote:
On Mon, Jul 21, 2008 at 4:51 AM, Christian Franke
... wrote:
This adds Cygwin support to kernel sources. It handles the issues
introduced by PE-ELF conversion and adds support for
HAVE_ASM_USCORE.
Christian
2007-07-20 Christian Franke [EMAIL PROTECTED]
*
Bean wrote:
Hi,
BTW, if you have time, you can consider writing a tool that convert pe
to elf directly, thus avoiding objcopy altogether. This shouldn't be
too difficult, you can take a look at util/i386/efi/grub-mkimage.c,
which does exactly the opposite, converting elf to pe32.
Hi,
El lun, 21-07-2008 a las 11:13 +0200, Jean-Christophe Haessig escribió:
Le dimanche 20 juillet 2008 à 17:06 +0200, Javier Martín a écrit :
Hi,
This should have been fixed by the transition to LZMA as the compression
algorithm for PC - core.img should now be under 32K and embeddable in
On Mon, Jul 21, 2008 at 6:33 PM, Christian Franke
[EMAIL PROTECTED] wrote:
Hi,
due to the complexity of PE, a stand-alone converter may likely be
larger than the ~680 LoC converter I already offered here. It was
rejected, see this thread:
El lun, 21-07-2008 a las 12:33 +0200, Christian Franke escribió:
Bean wrote:
BTW, if you have time, you can consider writing a tool that convert pe
to elf directly, thus avoiding objcopy altogether. This shouldn't be
too difficult, you can take a look at util/i386/efi/grub-mkimage.c,
El lun, 21-07-2008 a las 02:55 +0200, Javier Martín escribió:
(...)
Phew! That was long, even after removing some parts. Well, this is the
new version of the patch. Cheers!
As always, I'm so stupid that I left the patch out... Sigh. Here it is.
Habbit
Index: commands/i386/pc/drivemap.c
Committed.
--
Bean
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
El lun, 21-07-2008 a las 14:49 +0200, Marco Gerards escribió:
Pavel Roskin [EMAIL PROTECTED] writes:
On Sun, 2008-07-20 at 20:55 +0200, Marco Gerards wrote:
Pavel Roskin [EMAIL PROTECTED] writes:
I know. That's why I'll write it from specifications or maybe I'll
take it from the
On Mon, 21 Jul 2008 01:49:52 +0200
Simon Peter [EMAIL PROTECTED] wrote:
Did the message below ever arrive on the list?
I'm still interested in getting strong crypto into grub mainline and
while it's still not in, I just saw you guys proposed this as a
project for Google's summer of code.
Javier Martín [EMAIL PROTECTED] writes:
El lun, 21-07-2008 a las 14:49 +0200, Marco Gerards escribió:
Pavel Roskin [EMAIL PROTECTED] writes:
On Sun, 2008-07-20 at 20:55 +0200, Marco Gerards wrote:
Pavel Roskin [EMAIL PROTECTED] writes:
I know. That's why I'll write it from
El lun, 21-07-2008 a las 17:20 +0200, Marco Gerards escribió:
Javier Martín [EMAIL PROTECTED] writes:
El lun, 21-07-2008 a las 14:49 +0200, Marco Gerards escribió:
Pavel Roskin [EMAIL PROTECTED] writes:
On Sun, 2008-07-20 at 20:55 +0200, Marco Gerards wrote:
Pavel Roskin [EMAIL
On Mon, 2008-07-21 at 17:20 +0200, Marco Gerards wrote:
Javier Martín [EMAIL PROTECTED] writes:
So what? Aren't both Linux and GRUB under the GPL? That _should_ mean
that we can look at their code and put it into GRUB (create a
derivative work) either as-is or modified.
For GRUB 2 we
On Mon, 2008-07-21 at 13:02 +0200, Javier Martín wrote:
El lun, 21-07-2008 a las 12:33 +0200, Christian Franke escribió:
due to the complexity of PE, a stand-alone converter may likely be
larger than the ~680 LoC converter I already offered here.
Why do we even consider a PE-ELF converter? I
Pavel Roskin [EMAIL PROTECTED] writes:
On Mon, 2008-07-21 at 17:20 +0200, Marco Gerards wrote:
Javier Martín [EMAIL PROTECTED] writes:
So what? Aren't both Linux and GRUB under the GPL? That _should_ mean
that we can look at their code and put it into GRUB (create a
derivative work)
Javier Martín [EMAIL PROTECTED] writes:
El lun, 21-07-2008 a las 17:20 +0200, Marco Gerards escribió:
Javier Martín [EMAIL PROTECTED] writes:
El lun, 21-07-2008 a las 14:49 +0200, Marco Gerards escribió:
Pavel Roskin [EMAIL PROTECTED] writes:
On Sun, 2008-07-20 at 20:55 +0200, Marco
On Mon, 2008-07-21 at 17:53 +0200, Marco Gerards wrote:
Please do not put words in my mouth, that is not what I said. I said
looking at Linux *code* should be avoided.
I agree with you. I was referring to what I did, not to what you said.
--
Regards,
Pavel Roskin
Pavel Roskin [EMAIL PROTECTED] writes:
On Mon, 2008-07-21 at 17:53 +0200, Marco Gerards wrote:
Please do not put words in my mouth, that is not what I said. I said
looking at Linux *code* should be avoided.
I agree with you. I was referring to what I did, not to what you said.
Good :-)
El lun, 21-07-2008 a las 11:51 -0400, Pavel Roskin escribió:
On Mon, 2008-07-21 at 13:02 +0200, Javier Martín wrote:
El lun, 21-07-2008 a las 12:33 +0200, Christian Franke escribió:
due to the complexity of PE, a stand-alone converter may likely be
larger than the ~680 LoC converter I
On Mon, 2008-07-21 at 18:50 +0200, Javier Martín wrote:
Of course, another way to go could be to allow the bootloader part of
GRUB to be built in PE format: it would just be a matter of writing
the PE counterparts to kern/elf.c and abstracting kern/dl.c a
bit (i.e. a lot of work). The
El lun, 21-07-2008 a las 13:03 -0400, Pavel Roskin escribió:
On Mon, 2008-07-21 at 18:50 +0200, Javier Martín wrote:
Of course, another way to go could be to allow the bootloader part of
GRUB to be built in PE format: it would just be a matter of writing
the PE counterparts to kern/elf.c
On Tue, Jul 22, 2008 at 1:27 AM, Marco Gerards [EMAIL PROTECTED] wrote:
Hi,
Bean [EMAIL PROTECTED] writes:
On Mon, Jul 21, 2008 at 4:02 AM, Marco Gerards [EMAIL PROTECTED] wrote:
Hi,
Bean [EMAIL PROTECTED] writes:
First of all, we can still keep rescue and normal command. But instead
of
Hello,
Last weekend we talked about menu loop (wrapping):
http://lists.gnu.org/archive/html/grub-devel/2008-07/msg00319.html
Conclusion: people here don't like it (we could discuss for ages, I
think :-) )
Second proposal that maybe was hidden in so much text: to make it to
work Home and End
On Tue, Jul 22, 2008 at 2:03 AM, Bean [EMAIL PROTECTED] wrote:
Your idea seems fine, but there is a slightly efficiency issue. For
example, when we need to call a function in the handler, we need to
acquire it using name. We need to do this in every call, as the
handler could be changed next
On Mon, 2008-07-21 at 19:23 +0200, Javier Martín wrote:
El lun, 21-07-2008 a las 13:03 -0400, Pavel Roskin escribió:
I think it's important to have a consistent format for modules.
I thought that two hours ago, but now I find no advantage other than the
sharing of modules between similar
What's missing to get my code into GRUB2 mainline?
I think you'll have to assign copyright to the FSF.
What part of it?
I learned that Michael Gorven already replaced the problematic parts
(RIPEMD and AES) with versions from libgcrypt. The rest of the code is
all GPL3. Is it about the extra
On Sat, 2008-07-19 at 22:16 +0200, Yoshinori K. Okuji wrote:
I am totally against ripping off device.map. Pavel's idea is too
idealistic,
and that regresses the flexibility.
Actually, it could be said that having device.map regresses flexibility.
Suppose I want to install GRUB on a flash
On Sat, 2008-07-19 at 17:14 +0200, Robert Millan wrote:
As I understand it, there are two cases where we have to hardcode the
drive number.
1) MBR and core.img (embedded or not) are on different drives.
If embedded, then they're not different drives (core.img is put right after
MBR).
Marco Gerards wrote:
Pavel Roskin [EMAIL PROTECTED] writes:
On Thu, 2008-07-03 at 20:21 +0200, Marco Gerards wrote:
Pavel Roskin [EMAIL PROTECTED] writes:
ChangeLog:
* fs/xfs.c (struct grub_xfs_dir_header): Use names similar to
those in Linux XFS code. Provide a way to
32 matches
Mail list logo