[ros-dev] multiboot.S patch in need of review, please

[Royce Mitchell III]

Mike Nordell wrote:

>I can't see why there should be any disagreement about this. The only
>logical piece of code to relocate it, is the same piece of code that loads
>it. Having the kernel relocate itself, while it is running from/in the very
>image that is to be relocated (!) is not only a bit tricky
>(http://svn.reactos.com/viewcvs/trunk/msvc6/ntoskrnl/ke_i386_multiboot.c?rev
>=8046), it's also quite fragile. Should some, any, little piece be changed
>like code injected or moved to prohibit short function call addressing, it
>will crash. Should anyone ever make a change in the belief they could access
>global data (like one usually can from a program), it will crash. Should the
>very critical link-order change, making the multiboot table i the binary
>move to outside the first 8192 bytes if the on-disk image, it will crash.
>  
>
We can easily make sure that both _main as well as _NtProcessStartup are 
at the beginning of the file via the linker. This will guarantee we 
always have short function call addressing. In the new xml build system 
we can easily mark the files that need to be at the beginning and 
document *why*.

It will only be a VERY short space of code where global data is 
inaccessible, and I would make sure that Alex or I document the code 
sufficiently to illustrate to anybody who cares to look that they can't 
access global variables there.

Documentation is always the key. Since I've taken the time to study and 
understand what multiboot.S is actually doing, I can also blog an 
article about how ntoskrnl begins life ( in addition to the inline 
documentation ).

>A PE binary normally knows nothing, and shouldn't (have to) know anything,
>about its on-disk binary stored format. It already has an entry in the PE
>header telling what/where the entrypoint of the program is. Multiboot on the
>other hand uses absolute physical addresses, including the entrypoint
>address (that doesn't even need to point to within the image itself) that it
>reads from the multiboot-header in the binary. There is no portable way for
>a PE binary to know at what physical offset from the start of the binary
>on-disk image a particular piece of code will be without knowing _exactly_
>how the linker will place stuff in the on-disk image at compile-time.
>Linker. Compile-time. Let it sink in a bit.
>  
>
The offsets used at compile time are fixed-up by the linker at link 
time. I don't see the problem.

>Having this hard-coded relationship between multiboot and ntoskrnl.exe makes
>porting harder and the kernel code harder to understand (and therefore
>maintain).
>  
>
This "complexity" is primarily isolated to multiboot.S, except for the 
self-reloc code that will be called from the beginning of _main(). At 
least that's the plan. We have two choices here:

1) Do it the way you are suggesting, which is the "clean" way, and 
presumably the "MS" way, and remain forever indebted to a multiboot 
compatible proxy loader. This, IMHO, doesn't make anything simpler, it 
just shuffles the complexity around.

2) Do it in a way that's multiboot compatible, so that we can be loaded 
by any boot loader people should choose to use. I'd personally much 
rather choose to be more compatible with FOSS boot loaders at this stage 
of the OS than with the MS way of doing things. This will make it very 
easy for dual-booters to use us, which is going to be more important 
sooner than later. I don't see it having any particularly significant 
effect on porting complexity. If we were to port ntoskrnl to another 
archiecture, we'd likely look at how other OS's handle getting 
multibooted on those architectures. We just duplicate that for that 
architecture, then call _main() and let it reloc itself in-memory.

>3. Have the boot-loader know whether or not /3G is present. This allows _it_
>to set up the architecture-specific initial page-table mappings. The benefit
>of this is, as I see it, that the boot loader is by necessity a very
>architecture specific piece of code, why it might as well follow what ntldr
>does. The kernel image would then, when it gets control, already be at the
>virtual address it's supposed to be, and it can freely access global data as
>it should have been able to do in the first place. This also has the obvious
>benefit that much of the _highly_ architecture-specific code can be removed
>from the kernel itself.
>
>That last point should really be the only argument that's needed.
>  
>
Except that the code is already isolated in the architecture-specific 
i386 directory. For that reason, I personally don't find it to be a very 
compelling argument.

All this being said, it was just a curiosity... hacking multiboot.S to 
support 2G and 3G dynamically only took a couple hours. Fixing ntoskrnl 
to reloc itself should also be an easy job. It's no skin off my back if 
people would rather remain forever tied to freeldr. I don't plan to be a 
dual-booter, and don't imagine after this is said and done that I will 
ever need to look at this section of code again. It's just that if we're 
going to discuss changes, we should strongly consider compatibility with 
the variety of bootloaders that our fellow geeks choose to use.

There's also the "social" reason why we should do it the way I've proposed:

1) the people most likely to complain about having to go through freeldr 
are people setting up dual-booting. This complaint *will* become a FAQ 
item, as it will forever come up as an issue.

2) the people most likely to complain about not having the cleaner 
design of freeldr are the ppl porting to a new architecture. Once it 
works, they won't complain any more.

There are far fewer new architectures to port ReactOS to than there are 
ppl who will one day be interested in actually running ReactOS. If we're 
going to choose a design, we should choose the one that causes the least 
complaints and "support issues" out of our up-and-coming fan-base.

--
Royce Mitchell III