|
|
| Next: [PATCH] kbuild fixes |
| Author |
Message |
Andi Kleen External

Since: Jul 07, 2006 Posts: 1925
|
Posted: Tue Aug 01, 2006 9:20 pm Post subject: Re: [PATCH 9/33] i386 boot: Add serial output support to the decompressor [Login to view extended thread Info.] Archived from groups: linux>kernel (more info?) |
|
|
"Eric W. Biederman" <ebiederm.DeleteThis@xmission.com> writes:
> }
> @@ -200,6 +224,178 @@ static void putstr(const char *s)
> outb_p(0xff & (pos >> 1), vidport+1);
> }
>
> +static void vid_console_init(void)
Please just use early_printk instead of reimplementing this.
I think it should work in this context too.
> +static inline int tolower(int ch)
> +{
> + return ch | 0x20;
> +}
> +
> +static inline int isdigit(int ch)
> +{
> + return (ch >= '0') && (ch <= '9');
> +}
> +
> +static inline int isxdigit(int ch)
> +{
> + ch = tolower(ch);
> + return isdigit(ch) || ((ch >= 'a') && (ch <= 'f'));
> +}
And please reuse the Linux code here.
Actually the best way to reuse would be to first do 64bit uncompressor
and linker directly, but short of that #includes would be fine too.
> +
> +
> +static inline int digval(int ch)
> +{
> + return isdigit(ch)? (ch - '0') : tolower(ch) - 'a' + 10;
> +}
> +
> +/**
> + * simple_strtou - convert a string to an unsigned
> + * @cp: The start of the string
> + * @endp: A pointer to the end of the parsed string will be placed here
> + * @base: The number base to use
> + */
> +static unsigned simple_strtou(const char *cp, char **endp, unsigned base)
> +{
> + unsigned result = 0,value;
> +
> + if (!base) {
> + base = 10;
> + if (*cp == '0') {
> + base = 8;
> + cp++;
> + if ((tolower(*cp) == 'x') && isxdigit(cp[1])) {
> + cp++;
> + base = 16;
> + }
> + }
> + } else if (base == 16) {
> + if (cp[0] == '0' && tolower(cp[1]) == 'x')
> + cp += 2;
> + }
> + while (isxdigit(*cp) && ((value = digval(*cp)) < base)) {
> + result = result*base + value;
> + cp++;
> + }
> + if (endp)
> + *endp = (char *)cp;
> + return result;
> +}
Can you please somehow reuse the Linux one?
> +
> static void* memset(void* s, int c, unsigned n)
> {
> int i;
> @@ -218,6 +414,29 @@ static void* memcpy(void* dest, const vo
> return dest;
> }
>
> +static int memcmp(const void *s1, const void *s2, unsigned n)
> +{
> + const unsigned char *str1 = s1, *str2 = s2;
> + size_t i;
> + int result = 0;
> + for(i = 0; (result == 0) && (i < n); i++) {
> + result = *str1++ - *str2++;
> + }
> + return result;
> +}
> +
> +char *strstr(const char *haystack, const char *needle)
> +{
> + size_t len;
> + len = strlen(needle);
> + while(*haystack) {
> + if (memcmp(haystack, needle, len) == 0)
> + return (char *)haystack;
> + haystack++;
> + }
> + return NULL;
Would be better to just pull in lib/string.c
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Andi Kleen External

Since: Jul 07, 2006 Posts: 1925
|
Posted: Tue Aug 01, 2006 9:20 pm Post subject: Re: [PATCH 28/33] x86_64: Remove the identity mapping as early as possible. [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
"Eric W. Biederman" <ebiederm.RemoveThis@xmission.com> writes:
> With the rewrite of the SMP trampoline and the early page
> allocator there is nothing that needs identity mapped pages,
> once we start executing C code.
Cool.
Hopefully that can be done for i386 too. People on other architectures
have been complaining that i386 doesn't catch early NULL pointers.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Andi Kleen External

Since: Jul 07, 2006 Posts: 1925
|
Posted: Tue Aug 01, 2006 9:20 pm Post subject: Re: [PATCH 25/33] x86_64: 64bit PIC SMP trampoline [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
"Eric W. Biederman" <ebiederm RemoveThis @xmission.com> writes:
> - ljmpl $__KERNEL32_CS, $(startup_32-__START_KERNEL_map)
> +
> + # flush prefetch and jump to startup_32
> + ljmpl *(startup_32_vector - r_base)
> +
> + .code32
> + .balign 4
> +startup_32:
It would be nicer if you could factor out that code into
a common file between head.S and trampoline.S
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Vivek Goyal External

Since: May 15, 2006 Posts: 286
|
Posted: Tue Aug 01, 2006 9:30 pm Post subject: Re: [RFC] ELF Relocatable x86 and x86_64 bzImages [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
On Tue, Aug 01, 2006 at 04:58:49AM -0600, Eric W. Biederman wrote:
>
> The problem:
>
> We can't always run the kernel at 1MB or 2MB, and so people who need
> different addresses must build multiple kernels. The bzImage format
> can't even represent loading a kernel at other than it's default address.
> With kexec on panic now starting to be used by distros having a kernel
> not running at the default load address is starting to become common.
>
> The goal of this patch series is to build kernels that are relocatable
> at run time, and to extend the bzImage format to make it capable of
> expressing a relocatable kernel.
>
> In extending the bzImage format I am replacing the existing unused bootsector
> with an ELF header. To express what is going on the ELF header will
> have type ET_DYN. Just like the kernel loading an ET_DYN executable
> bootloaders are not expected to process relocations. But the executable
> may be shifted in the address space so long as it's alignment requirements
> are met.
>
> The x86_64 kernel is simply built to live at a fixed virtual address
> and the boot page tables are relocated. The i386 kernel is built
> to process relocations generated with --embedded-relocs (after vmlinux.lds.S)
> has been fixed up to sort out static and dynamic relocations.
Hi Eric,
Can't we use the x86_64 relocation approach for i386 as well? I mean keep
the virtual address space fixed and updating the page tables. This would
help in the sense that you don't have to change gdb if somebody decides to
debug the relocated kernel.
Any such tool that retrieves the symbol virtual address from vmlinux will
be confused.
Thanks
Vivek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Jan Kratochvil External

Since: Aug 01, 2006 Posts: 1
|
Posted: Tue Aug 01, 2006 10:20 pm Post subject: Re: [RFC] ELF Relocatable x86 and x86_64 bzImages [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
On Tue, 01 Aug 2006 21:26:28 +0200, Vivek Goyal wrote:
....
> Can't we use the x86_64 relocation approach for i386 as well? I mean keep
> the virtual address space fixed and updating the page tables. This would
> help in the sense that you don't have to change gdb if somebody decides to
> debug the relocated kernel.
This is exactly the approach of mkdump version <=1.0
http://mkdump.sourceforge.net/
As documented by Itsuro Oda:
http://mkdump.cvs.sourceforge.net/mkdump/doc/mini_kernel_tech_note.txt?revision=1.1
There is a problem all the drivers expect that allocated buffer address can be
passed directly as physical address to the hardware. mkdump-1.0 has a lot of
backward-mappings for these drivers but you can never catch all of them.
Regards,
Lace
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
H. Peter Anvin External

Since: Feb 08, 2006 Posts: 1055
|
Posted: Tue Aug 01, 2006 10:30 pm Post subject: Re: [RFC] ELF Relocatable x86 and x86_64 bzImages [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
Vivek Goyal wrote:
>
> Hi Eric,
>
> Can't we use the x86_64 relocation approach for i386 as well? I mean keep
> the virtual address space fixed and updating the page tables. This would
> help in the sense that you don't have to change gdb if somebody decides to
> debug the relocated kernel.
>
> Any such tool that retrieves the symbol virtual address from vmlinux will
> be confused.
>
I don't think this is practical given the virtual space constraints on
i386 systems.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Vivek Goyal External

Since: May 15, 2006 Posts: 286
|
Posted: Tue Aug 01, 2006 10:50 pm Post subject: Re: [RFC] ELF Relocatable x86 and x86_64 bzImages [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
On Tue, Aug 01, 2006 at 04:58:49AM -0600, Eric W. Biederman wrote:
>
> Currently there are 33 patches in my tree to do this.
>
> The weirdest symptom I have had so far is that page faults did not
> trigger the early exception handler on x86_64 (instead I got a reboot).
>
> There is one outstanding issue where I am probably requiring too much alignment
> on the arch/i386 kernel.
>
> Can anyone find anything else?
>
I am running into compilation failure on x86_64.
SYSMAP System.map
SYSMAP .tmp_System.map
AS arch/x86_64/boot/bootsect.o
In file included from include/asm/bitops.h:9,
from include/linux/bitops.h:10,
from include/linux/kernel.h:16,
from include/asm/system.h:5,
from include/asm/processor.h:19,
from include/asm/elf.h:11,
from include/linux/elf.h:8,
from arch/x86_64/boot/bootsect.S:20:
include/asm/alternative.h:73: error: syntax error in macro parameter list
include/asm/alternative.h:88: error: syntax error in macro parameter list
include/asm/alternative.h:127: error: syntax error in macro parameter list
In file included from include/asm/system.h:5,
from include/asm/processor.h:19,
from include/asm/elf.h:11,
from include/linux/elf.h:8,
from arch/x86_64/boot/bootsect.S:20:
include/linux/kernel.h:34: warning: "ALIGN" redefined
In file included from include/linux/kernel.h:12,
from include/asm/system.h:5,
from include/asm/processor.h:19,
from include/asm/elf.h:11,
from include/linux/elf.h:8,
from arch/x86_64/boot/bootsect.S:20:
include/linux/linkage.h:27: warning: this is the location of the previous definition
In file included from include/asm/system.h:5,
from include/asm/processor.h:19,
from include/asm/elf.h:11,
from include/linux/elf.h:8,
from arch/x86_64/boot/bootsect.S:20:
include/linux/kernel.h:216: error: syntax error in macro parameter list
include/linux/kernel.h:220: error: syntax error in macro parameter list
In file included from include/linux/sched.h:55,
from include/asm/compat.h:9,
from include/asm/elf.h:12,
from include/linux/elf.h:8,
from arch/x86_64/boot/bootsect.S:20:
include/linux/nodemask.h:229: error: detected recursion whilst expanding macro "find_first_bit"
include/linux/nodemask.h:235: error: detected recursion whilst expanding macro "find_next_bit"
include/linux/nodemask.h:254: error: detected recursion whilst expanding macro "find_first_zero_bit"
arch/x86_64/boot/bootsect.S:21: error: linux/elf_boot.h: No such file or directory
make[1]: *** [arch/x86_64/boot/bootsect.o] Error 1
make: *** [bzImage] Error 2
Thanks
Vivek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Jeremy Fitzhardinge External

Since: May 30, 2006 Posts: 1261
|
Posted: Wed Aug 02, 2006 12:20 am Post subject: Re: [PATCH 11/33] i386 boot: Add an ELF header to bzImage [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
Eric W. Biederman wrote:
> +.macro note name, type
> + .balign 4
> + .int 2f - 1f # n_namesz
> + .int 4f - 3f # n_descsz
> + .int \type # n_type
> + .balign 4
> +1: .asciz "\name"
> +2: .balign 4
> +3:
> +.endm
> +.macro enote
> +4: .balign 4
> +.endm
>
This is very similar to the macro I introduced in the Paravirt note
segment patch. Do think they should be made common?
> +/* Elf notes to help bootloaders identify what program they are booting.
> + */
> +
> +/* Standardized Elf image notes for booting... The name for all of these is ELFBoot */
> +#define ELF_NOTE_BOOT "ELFBoot"
>
I wonder if this should be something to suggest its Linux-specific? Or
do you see this being used by a wider audience?
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Eric W. Biederman External

Since: May 19, 2006 Posts: 1134
|
Posted: Wed Aug 02, 2006 4:10 am Post subject: Re: [RFC] ELF Relocatable x86 and x86_64 bzImages [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
"H. Peter Anvin" <hpa.RemoveThis@zytor.com> writes:
> Vivek Goyal wrote:
>> Hi Eric,
>> Can't we use the x86_64 relocation approach for i386 as well? I mean keep
>> the virtual address space fixed and updating the page tables. This would
>> help in the sense that you don't have to change gdb if somebody decides to
>> debug the relocated kernel.
>> Any such tool that retrieves the symbol virtual address from vmlinux will
>> be confused.
>>
>
> I don't think this is practical given the virtual space constraints on i386
> systems.
Exactly.
Plus it is a lot of dangerous work. Processing is a lot more
conservative.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Eric W. Biederman External

Since: May 19, 2006 Posts: 1134
|
Posted: Wed Aug 02, 2006 4:20 am Post subject: Re: [PATCH 18/33] x86_64: Kill temp_boot_pmds [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
Andi Kleen <ak.DeleteThis@suse.de> writes:
> "Eric W. Biederman" <ebiederm.DeleteThis@xmission.com> writes:
>>
>> I also modify the early page table initialization code
>> to use early_ioreamp and early_iounmap, instead of the
>> special case version of those functions that they are
>> now calling.
>
> Ok valuable cleanup. I queued that one too.
>
>> The only really silly part left with init_memory_mapping
>> is that find_early_table_space always finds pages below 1M.
>
> I fixed this some time ago - obsolete comment?
Yes an obsolete comment. I thought I had rechecked that
but I was skimming to fast. find_e820_memory certainly
isn't limited to pages below 1M.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Eric W. Biederman External

Since: May 19, 2006 Posts: 1134
|
Posted: Wed Aug 02, 2006 4:20 am Post subject: Re: [PATCH 18/33] x86_64: Kill temp_boot_pmds II [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
Andi Kleen <ak RemoveThis @suse.de> writes:
> "Eric W. Biederman" <ebiederm RemoveThis @xmission.com> writes:
>>
>> I also modify the early page table initialization code
>> to use early_ioreamp and early_iounmap, instead of the
>> special case version of those functions that they are
>> now calling.
>
> Or rather I tried to apply it - it doesn't apply at all
> on its own:
>
> patching file arch/x86_64/mm/init.c
> Hunk #1 FAILED at 167.
> Hunk #2 succeeded at 274 with fuzz 1 (offset 28 lines).
> Hunk #3 FAILED at 286.
> Hunk #4 FAILED at 341.
> 3 out of 4 hunks FAILED -- rejects in file arch/x86_64/mm/init.c
It is probably patch 17:
"x86_64: Separate normal memory map initialization from the hotplug case"
I don't see any other patches that touch arch/x86_64/mm/init.c
before that. At least not in 2.6.18-rc3, which is the base of
my patchset.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Eric W. Biederman External

Since: May 19, 2006 Posts: 1134
|
Posted: Wed Aug 02, 2006 4:30 am Post subject: Re: [PATCH 4/33] i386: CONFIG_PHYSICAL_START cleanup [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
Sam Ravnborg <sam DeleteThis @ravnborg.org> writes:
>> diff --git a/arch/i386/boot/compressed/head.S
> b/arch/i386/boot/compressed/head.S
>> index b5893e4..8f28ecd 100644
>> --- a/arch/i386/boot/compressed/head.S
>> +++ b/arch/i386/boot/compressed/head.S
>> @@ -23,9 +23,9 @@
>> */
>> .text
>>
>> +#include <linux/config.h>
>
> You already have full access to all CONFIG_* symbols - kbuild includes
> it on the commandline. So please kill this include.
Ok. That must be new. No problem.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Eric W. Biederman External

Since: May 19, 2006 Posts: 1134
|
Posted: Wed Aug 02, 2006 4:30 am Post subject: Re: [PATCH 32/33] x86_64: Relocatable kernel support [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
Andi Kleen <ak.TakeThisOut@suse.de> writes:
> "Eric W. Biederman" <ebiederm.TakeThisOut@xmission.com> writes:
>>
>> When loaded with a normal bootloader the decompressor will decompress
>> the kernel to 2M and it will run there. This both ensures the
>> relocation code is always working, and makes it easier to use 2M
>> pages for the kernel and the cpu.
>
> It would have been nicer if you had moved the uncompressor to be 64bit
> first like it was planned for a long time.
Sorry. I wasn't really in those discussions.
I guess I could take this in some slightly smaller steps.
But this does wind up with decompressor being 64bit code.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Eric W. Biederman External

Since: May 19, 2006 Posts: 1134
|
Posted: Wed Aug 02, 2006 4:30 am Post subject: Re: [PATCH 2/33] i386: define __pa_symbol [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
Andi Kleen <ak.TakeThisOut@suse.de> writes:
> "Eric W. Biederman" <ebiederm.TakeThisOut@xmission.com> writes:
>
>> On x86_64 we have to be careful with calculating the physical
>> address of kernel symbols. Both because of compiler odditities
>> and because the symbols live in a different range of the virtual
>> address space.
>>
>> Having a defintition of __pa_symbol that works on both x86_64 and
>> i386 simplifies writing code that works for both x86_64 and
>> i386 that has these kinds of dependencies.
>>
>> So this patch adds the trivial i386 __pa_symbol definition.
>>
>> Signed-off-by: Eric W. Biederman <ebiederm.TakeThisOut@xmission.com>
>> ---
>> include/asm-i386/page.h | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/asm-i386/page.h b/include/asm-i386/page.h
>> index f5bf544..eceb7f5 100644
>> --- a/include/asm-i386/page.h
>> +++ b/include/asm-i386/page.h
>> @@ -124,6 +124,7 @@ #define PAGE_OFFSET ((unsigned long)__P
>> #define VMALLOC_RESERVE ((unsigned long)__VMALLOC_RESERVE)
>> #define MAXMEM (-__PAGE_OFFSET-__VMALLOC_RESERVE)
>> #define __pa(x) ((unsigned long)(x)-PAGE_OFFSET)
>> +#define __pa_symbol(x) __pa(x)
>
> Actually PAGE_OFFSET arithmetic on symbols is outside ISO C and gcc
> misoptimizes it occassionally. You would need to use HIDE_RELOC
> or similar. That is why x86-64 has the magic.
Yes. ISO C only defines pointer arithmetic with in arrays.
I believe gnu C makes it a well defined case.
Currently we do not appear to have any problems on i386.
But I have at least one case of code that is shared between
i386 and x86_64 and it is appropriate to use __pa_symbol on
x86_64.
So I added __pa_symbol for that practical reason.
I would have no problems with generalizing this but I wanted to
at least make it possible to use the concept on i386.
I will be happy to add in the assembly magic, if you don't have
any other problems with this.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Eric W. Biederman External

Since: May 19, 2006 Posts: 1134
|
Posted: Wed Aug 02, 2006 4:40 am Post subject: Re: [PATCH 9/33] i386 boot: Add serial output support to the decompressor [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
Andi Kleen <ak DeleteThis @suse.de> writes:
> "Eric W. Biederman" <ebiederm DeleteThis @xmission.com> writes:
>> }
>> @@ -200,6 +224,178 @@ static void putstr(const char *s)
>> outb_p(0xff & (pos >> 1), vidport+1);
>> }
>>
>> +static void vid_console_init(void)
>
> Please just use early_printk instead of reimplementing this.
> I think it should work in this context too.
It doesn't or at least it didn't. I can look again though.
>> +static inline int tolower(int ch)
>> +{
>> + return ch | 0x20;
>> +}
>> +
>> +static inline int isdigit(int ch)
>> +{
>> + return (ch >= '0') && (ch <= '9');
>> +}
>> +
>> +static inline int isxdigit(int ch)
>> +{
>> + ch = tolower(ch);
>> + return isdigit(ch) || ((ch >= 'a') && (ch <= 'f'));
>> +}
>
> And please reuse the Linux code here.
Reuse is hard because we really are a separate executable,
in a slightly different environment.
> Actually the best way to reuse would be to first do 64bit uncompressor
> and linker directly, but short of that #includes would be fine too.
> Would be better to just pull in lib/string.c
Maybe. Size is fairly important here so I am concerned that I
will pull in more than I need. But look and see if I can pull
in just a subset of what is needed.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Eric W. Biederman External

Since: May 19, 2006 Posts: 1134
|
Posted: Wed Aug 02, 2006 4:50 am Post subject: Re: [RFC] ELF Relocatable x86 and x86_64 bzImages [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
Vivek Goyal <vgoyal.DeleteThis@in.ibm.com> writes:
> On Tue, Aug 01, 2006 at 04:58:49AM -0600, Eric W. Biederman wrote:
>>
>> Currently there are 33 patches in my tree to do this.
>>
>> The weirdest symptom I have had so far is that page faults did not
>> trigger the early exception handler on x86_64 (instead I got a reboot).
>>
>> There is one outstanding issue where I am probably requiring too much
> alignment
>> on the arch/i386 kernel.
>>
>> Can anyone find anything else?
>>
>
> I am running into compilation failure on x86_64.
I'm not quite certain what is wrong, except that you haven't
applied all of my patches.
The x86_64 ones do depend on the i386 ones to some extent.
That is why it was one giant patchset.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Eric W. Biederman External

Since: May 19, 2006 Posts: 1134
|
Posted: Wed Aug 02, 2006 4:50 am Post subject: Re: [PATCH 11/33] i386 boot: Add an ELF header to bzImage [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
Jeremy Fitzhardinge <jeremy.RemoveThis@goop.org> writes:
> Eric W. Biederman wrote:
>> +.macro note name, type
>> + .balign 4
>> + .int 2f - 1f # n_namesz
>> + .int 4f - 3f # n_descsz
>> + .int \type # n_type
>> + .balign 4
>> +1: .asciz "\name"
>> +2: .balign 4
>> +3:
>> +.endm
>> +.macro enote
>> +4: .balign 4
>> +.endm
>>
>
> This is very similar to the macro I introduced in the Paravirt note segment
> patch. Do think they should be made common?
Yes. At the point of merging these two approaches I think the notes
should just be put into vmlinux and copied either into the ELF
header or more likely into a segment that build.c tacks onto
the kernel.
It is such a small piece of my overall picture I wasn't really looking
at that.
>> +/* Elf notes to help bootloaders identify what program they are booting.
>> + */
>> +
>> +/* Standardized Elf image notes for booting... The name for all of these is
> ELFBoot */
>> +#define ELF_NOTE_BOOT "ELFBoot"
>>
>
> I wonder if this should be something to suggest its Linux-specific? Or do you
> see this being used by a wider audience?
This note is used in etherboot and LinuxBIOS right now so it isn't terribly linux
specific. And whatever the virtues of it's name it is actually in use.
I had a preliminary RFC for using these in a winder context at one point but I
ran out of energy for pushing it.
I think the information in those note headers is interesting beyond that I
really don't much care.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Eric W. Biederman External

Since: May 19, 2006 Posts: 1134
|
Posted: Wed Aug 02, 2006 5:10 am Post subject: Re: [PATCH 9/33] i386 boot: Add serial output support to the decompressor [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
Andi Kleen <ak.RemoveThis@suse.de> writes:
> "Eric W. Biederman" <ebiederm.RemoveThis@xmission.com> writes:
>> }
>> @@ -200,6 +224,178 @@ static void putstr(const char *s)
>> outb_p(0xff & (pos >> 1), vidport+1);
>> }
>>
>> +static void vid_console_init(void)
>
> Please just use early_printk instead of reimplementing this.
> I think it should work in this context too.
There is certainly some value in that. To do that I would
need to refactor early_printk to make it useable.
This comment from one of patches summaries the worst of the problems.
> /* WARNING!!
> * This code is compiled with -fPIC and it is relocated dynamically
> * at run time, but no relocation processing is performed.
> * This means that it is not safe to place pointers in static structures.
> */
lib/string.c might be useful. The fact that the functions are not
static slightly concerns me. I have a vague memory of non-static
functions generating relocations for no good reason.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Andi Kleen External

Since: Jul 07, 2006 Posts: 1925
|
Posted: Wed Aug 02, 2006 5:20 am Post subject: Re: [PATCH 9/33] i386 boot: Add serial output support to the decompressor [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
> > /* WARNING!!
> > * This code is compiled with -fPIC and it is relocated dynamically
> > * at run time, but no relocation processing is performed.
> > * This means that it is not safe to place pointers in static structures.
> > */
iirc the only static relocation in early_printk is the one to initialize
the console pointers - that could certainly be moved to be at run time.
> lib/string.c might be useful. The fact that the functions are not
> static slightly concerns me. I have a vague memory of non-static
> functions generating relocations for no good reason.
Would surprise me.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
Andi Kleen External

Since: Jul 07, 2006 Posts: 1925
|
Posted: Wed Aug 02, 2006 5:20 am Post subject: Re: [PATCH 9/33] i386 boot: Add serial output support to the decompressor [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
> > Actually the best way to reuse would be to first do 64bit uncompressor
> > and linker directly, but short of that #includes would be fine too.
>
> > Would be better to just pull in lib/string.c
>
> Maybe. Size is fairly important
Why is size important here?
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/ |
|
| Back to top |
|
 |
|
|
|
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
| |
|
|