Eric W. Biederman wrote:
> Etienne Lorrain <[email protected]> writes:
>> Well, if the function called at offset 0 in the real-mode section return
>> non zero, that is probably an error - that is Gujin interface, but do not ask
>> me to change other bootloaders to handle that.
>> This function is called with few parameters, one is a string pointer
>> if the function do not want to print the problem report itself.
>> The function is called with an offset of zero in its own intel
>> segment.
>
> So I think there are some backwards compatibility issues with your
> real mode code interface. Setting a new flag that says to return instead
> of printing an error message and halting would be one way to handle
> this.
I am not sure to understand: Gujin calls a function inside the ELF real
mode program header of the Linux kernel. All the system is currently
in real mode. There isn't any limitation in this function of the kernel to
decide to print some message and not return at all, this function can
selectively do so by reading which bootloader ID it is using (another
parameter). It is not done mostly because "printf" is difficult to do
in assembler, Gujin has no problem.
> Is your real mode C code section relative such that it can be loaded
> at different addresses and still work?
The code is relative - but not the data (first 4 Kbytes at %ds:0 and stack
available) - but the whole lot at any segment boundary, i.e. every 16 bytes.
Else Gujin would not work under DOS.
> The program header is for executable loaders the section header is for
> linkers and the section header is optional in PT_LOAD and PT_DYN
> executables. Use of the section header by a loader is a bug.
Unless if there is a problem, Gujin uses only the program header;
it has a look in the section header just in case - that can be removed
easily. I was wondering about a relocatable image there - but I do
not know enough for that.
> There have been limitations but mostly with respect to page table size
> and the like but they were not limitations a bootloader had to deal with.
Was talking about this comment, but it is old:
/* 0x28000*16 = 2.5 MB, conservative estimate for the current maximum */
http://lxr.linux.no/source/arch/i386/boot/tools/build.c?v=2.4.28
> > Well, you can generate with the proposed patch and boot with SYSLINUX,
> > Grub and LILO, but trying to clean Linux real-mode code is where I begun.
>
> I haven't looked yet. But I believe this is something that we can do,
> so long as cleaning and feature enhancement are not mixed in a bad way.
> Phrasing this another way. What we can do with the interface is
> determined our interface to existing bootloaders and what bootloaders
> exist. Basically it is the rule that we need to preserve backwards
> compatibility and changes generally need to be evolutionary ones.
Well, if you want to preserve compatibility with other bootloaders,
it is probably possible to put some source around the ELF kernel file,
mostly taken from Gujin if you want (GPL), but I wonder why you would
like to be compatible with LILO.
Modifying the linux real mode assembler, nobody could even want to.
Etienne.
___________________________________________________________________________
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses
http://fr.answers.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
