DragonFly kernel List (threaded) for 2010-01
Re: 64-bit vkernel
:known until run-time. So the vkernel needs to deal with virtual
:addresses as seen by the kernel, virtual addresses as seen by the
:"hardware" and physical addresses. The greatest inconvenience is that
:you cannot treat the kernel pmap and user pmaps in a uniform way.
:I'd like to propose the following:
:When servicing VM faults in ranges governed by virtual page tables, the
:actual virtual address to be used for the vpagetable translation, and
:not the offset from the beginning of the range.
:This change will remove the two classes of virtual addresses that now
:exist, but it breaks the assumption that faults are serviced based on VM
:object and page index within the object. This only matters to the
:vkernel, because it is the only kind of process that uses
:Do you have any thoughts on what I propose?
: Jordan Gordeev
The issue has to do with the vkernel not having a boot loader.
So the vkernel binary is loaded as a normal ELF program by the
normal rtelf-elf, libc, etc code. This portion of the vkernel,
along with any incidental malloc()'s done by libc and friends,
does not use the mapped vpagetable area.
I'm not sure what you are proposing in terms of coding. Are
you talking about changing the KernelPTA calculation in the
vkernel code and the related pmaps? If so I think it is a good