On 2/14/07, Ernesto Bascon <[EMAIL PROTECTED]> wrote:
Great!!! I am a C, C++, some x86 assembler, Java, C# application developer, so, I have no experience working on kernel development! If you could "show me the way" from the start, should be perfect for me :)
Basically , porting DragonFly to amd64 platform doesn't involve only kernel work. We need to port kernel as well as userland. I read a mail from 'corecode' that he cleaned up the userland so that he was able to make buildworld with TARGET_ARCH=amd64 but I couldn't find the patch. Anyway first we need a kernel in place.
"Well, basically I've only focussed on locore and pmap right now. I have some header files done, locore.s, and I'm still shuffling files around between platform/pc64 and cpu/x86_64. I think that once the layout of KVA and the pmap code are reasonably done, the rest of the kernel side can be worked on.
If you are familiar with the FreeBSD booting process then the file locore.s contains the code which is a starting point from loader to the real kernel. In FreeBSD locore.s sets up bootstack and calls hammer_stack (sys/amd64/amd64/machdep.c) which is a machine dependent initialization and then it calls mi_startup(sys/kern/init_main.c) which mounts root file system and creates process 0. The pmap.c code is machine dependent interface to the memory management unit. The machine independent (virtual memory subsystem) code is in /usr/src/sys/vm directory.
As far as the VA space is concerned, I am thinking that we shouldn't reserve the entire upper half of usable VA space (the 256 uppermost entries in the PML4 that's active), because I don't want to consume too much memory for the kernel, even though the usable VA space is (way) larger than the usable PA space. I don't think the kernel will ever need the full 128TiB the upper half of usable VA space maps; Whereas it is currently hard to imagine DFly ever running on machines with such amounts of RAM, I don't see it impossible in the future; and I'd rather have userland apps be able to consume >128TiB of memory, than the kernel having 128TiB which it won't ever use. Ofcourse, given the limitations in the current x86_64 implementations regarding PA space, that's not really realistic right now, but I guess you got my point." </Thomas>
I think we should follow the Matt's design for the same. Read the following post from Matt. http://leaf.dragonflybsd.org/mailarchive/commits/2004-02/msg00011.html Cheers kmb -- Something is wrong up on cloud # 9!
