Re: AMD64 Support

["km b" <kmb810@xxxxxxxxx>]

On 2/14/07, Ernesto Bascon <ebasconp@gmail.com> 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!