OSDev.org

..

Hmmm ...

I don't see neither advantage nor disadvantage in locating the kernel space in the lower gigabyte of adress space.

the only thing I see at the moment is: if you 're going to use vm86 mode, you're likely to have the vm86 task run in kernel adress space. this is Maybe Dangerous(tm). I've achieved a split between the vm86 adress space (0x00000000 - 0x001fffff) and kernel land by locating the kernel at 0xc0000000. any other location would 've been good as well. With paging, it really doesn't matter, and the processor traps into kernel space when a gpf occurs in vm86 mode - so no problems.

In short: there is *no* reason for you not to do it.

hth & stay safe gosh

why in the known world would you ever need or want that much memory for the kernel in the first place? I mean i understand it is demand paged, but nonetheless, when would you need to swap 1GB+ for kernel memory? IMO a kernel should never have to use more than 128MB MAX as long as it does what is needed and not a bunch of fluff.

No, and the reason is V86. It's not Dangerous to run it in kernel space, it's Impossible. V86 mode is hard-coded to ring 3 and to the bottom 1MB of address space. If you put the kernel at the bottom, then it means that the bottom 1MB of any process which runs V86 must be accessible to user mode, so the kernel will really be at 0010_0000 to 0040_0000.

Regardless I think it's a lot cleaner to put the kernel at the top, say 8000_0000 to FFFF_FFFF.

@Tim: Oy, 've overseen that. Beg yer pardon . Didn't intend to send Perica on a Mission Impossible ];->.

mr. xsism wrote: why in the known world would you ever need or want that much memory for the kernel in the first place? I mean i understand it is demand paged, but nonetheless, when would you need to swap 1GB+ for kernel memory? IMO a kernel should never have to use more than 128MB MAX as long as it does what is needed and not a bunch of fluff.

As for x86 operating systems, the difference between 2GB and 3GB might be of some use to the user processes, but the difference between 3.5 and 3.75 won't really have any significant impact, aside from the kernel not being able to address everything it needs.

The kernel itself plus dynamic data should not have to use more than anything like 2MB, plus a possible 6MB for the drivers. But when you add all large-table-things, such as thread tables (which can be up to 16MB in my design) and page frame administration (up to 128MB), it gets tougher to fit it in 256MB, let alone 128MB.

Since the user will definately not have any noticeable profit from 3.75 or 3.87 GB making such an optimization is not necessary. Also, since shared libraries and shared memory also have to be mapped in this region, the user space gets smaller all the time. If you need more than 2GB, use 64-bit AMD's or Intel's.

That being said, you don't have to bother keeping more than half or 3/4 free for the user processes, and even then you can snoop (in my design, again).

I'm aiming at a workstation OS, so no games and no big databases, thereby limiting my OS to smaller applications, but a whole lot of them. Seems to make it not a reasonable thing to worry about...

Back to the topic then.

Mapping to 0x0 - 0x3FFFFFFF has no direct disadvantage. There is however one case in which there IS a difference you might be interested in. When you use both paging and V86 mode (not very uncommon), you have to map the page tables to 0x0 - 0x003FFFFF or 0xFFC00000 - 0xFFFFFFFF to make use of page directories that are also page tables, in other words, to save memory. If you map it to 0xFFFFFFFF, you might as well dump the kernel there. But, if you dump it to 0x0, you cannot run V86 mode programs, since they require 0x0 - 0x10FFEF to be their address space. I think this small reason is the reason why most, if not all, people choose for 0xC0000000 or 0xF0000000 (like me).

Note that the Linux kernel starts at C000_0000, and the Windows kernel starts at either 8000_0000 or C000_0000 depending on how it's configured.

..

Perica wrote:

Candy wrote:you have to map the page tables to 0x0 - 0x003FFFFF or 0xFFC00000 - 0xFFFFFFFF to make use of page directories that are also page tables, in other words, to save memory. If you map it to 0xFFFFFFFF, you might as well dump the kernel there.

I don't understand what you mean by this at all, could you please explain it.....

Well, stole that idea from Tim ::)

The idea is that the page tables and the page directories both have the same layout. That is, you can use a single page for both the page directory and the page table, saving you a whole lot of trouble (a lot simpler algorithms, ones without recursion).

If you map the page directory to 0xFFFFF000, and in that you map the top page table (the 0x3FF'th page table) to the page directory, the entry will be used by the CPU to map the page directory, the page directory will be checked (same page) for the page table you want, and the page table (again, same page) will be accessible at that point, without wasting other stuff.

the entry for the page table:
0xFFFFF000 = 1111111111 1111111111 1111111111 00
| page dir | page table| page offset|
| page dir | page offset|

the first one is the one the CPU uses for indexing, the second one is the one you use for updating the page table.

Hi!
I'm newbie on OS development, and I Want to know why to put the kernel on 0xC0000000? there is any special reason for that? Could it not be located in any other address?

It's up to you. Putting the kernel at C000_0000 to FFFF_FFFF makes user space 0000_0000 to BFFF_FFFF, which is 3GB. You could put the kernel lower, which would give more space for kernel and less for user, or vice versa.

Tim Robinson wrote: No, and the reason is V86. It's not Dangerous to run it in kernel space, it's Impossible.

Hmm ... i'd like to soften this a bit, Tim ... though i still haven't implemented it so far, but if all you want to do with VM86 is calling a few BIOS interrupts (i.e. if you do not need to support 8086 *programs* but only system services), you could play with the VM86's task page table so that only the few pages that hold BIOS code and VM86 buffers/code are user-accessible, keeping the rest of the kernel below 1MB, but still having it protected against VM through "U=0, W=0" page attributes.

Now, maybe this "solutions" sounds even worse than the problem itself...

..

All I can comment on that is that I wonder where you'll put your page tables? Or are you planning on not using paging?

I have been out of OS dev for a very long time, and I forgot most of what I know. So can someone tell me why, and how you couldd put a kernel at 3GB? I dont even know anyone with that much RAM. I just put mine 1MB up. The 3GB thing must be some form of virtual address, but why that, and how does it work?