Megalithic kernel's approach to memory

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Post Reply
User avatar
Civillian
Member
Member
Posts: 32
Joined: Tue Feb 21, 2012 3:26 pm

Megalithic kernel's approach to memory

Post by Civillian »

Hello.
I am unsure whether or not I should implement paging for my megalithic kernel.
Otherwise, judging from this, I'd setup up the distinct null, Code, Data and the "rest of memory" segments, correct?
Thank you.
User avatar
bluemoon
Member
Member
Posts: 1761
Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong

Re: Megalithic kernel's approach to memory

Post by bluemoon »

You would like to have paging if you want to present an uniform address space to the application (which then linked directly into kernel)
paging hide away the memory holes.
sandras
Member
Member
Posts: 146
Joined: Thu Nov 03, 2011 9:30 am

Re: Megalithic kernel's approach to memory

Post by sandras »

Does your kernel load binaries, or is it all just compiled into one blob, like the latter example in your first link says?

If you load binaries, you could either use relocatable code, or you could use paging and have protection. Paging has some other benefits too.

If the latter, all the paging you can do is only for the kernel, so it's as if there is no paging in the first place. unless you decide, you want to not see certain memory areas. But I don't see a big reason for that. Also, mapping your kernel somewhere else than the physical address will only complicate things, so it's either identity mapping, optionally with some areas you don't wanna see unmapped, or none at all, I suggest.

It depends on your wishes, but I would say, that processes should have their own address spaces. But then again, I don't even like the megalithic kernel approach.

Good luck.

Edit: And about the GDT. I'm not sure I understand you, but you should set up all the GDT entries, except the null one, from 0 to 0xFFFFFFFF. That's all the (possible) 4gb of memory.

Here's how I do it in my (kinda) bootloader:

Code: Select all

start:
	; Set up GDT so we can enter Protected Mode.
	lgdt	[gdt]

gdt:
	; Null descriptor + GDT self-descriptor in one to save 6 bytes. =)
	dw	23
	dd	gdt
	db	00000000b
	db	00000000b
	; Code descriptor.
	db	11111111b				; Limit		low.
	db	11111111b				; Limit		low.
	db	00000000b				; Base		low.
	db	00000000b				; Base		low.
	db	00000000b				; Base		middle.
	db	10011010b				; Access.
	db	11001111b				; Granularity.
	db	00000000b				; Base		high.
	; Data descriptor.
	db	11111111b				; Limit		low.
	db	11111111b				; Limit		low.
	db	00000000b				; Base		low.
	db	00000000b				; Base		low.
	db	00000000b				; Base		middle.
	db	10010010b				; Access.
	db	11001111b				; Granularity.
	db	00000000b				; Base		high.
I think this may need editing when I enter user space, but for now and for you it should do (such a poet).
User avatar
bluemoon
Member
Member
Posts: 1761
Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong

Re: Megalithic kernel's approach to memory

Post by bluemoon »

my descriptors:

Code: Select all

gdtr    dw  11 *8 -1
        dq  gdt
        dw  0
align 16
gdt     dd  0, 0
        dd  0, 0, 0, 0                          ; 0x08 TSS
        dd  0x00000000, 0x00209A00              ; 0x18 CODE64 DPL0
        dd  0x00000000, 0x00009200              ; 0x20 DATA64 DPL0
        dd  0x0000FFFF, 0x00CFFA00              ; 0x28 CODE32 DPL3
        dd  0x00000000, 0x0000F200              ; 0x30 DATA64 DPL3
        dd  0x00000000, 0x0020FA00              ; 0x38 CODE64 DPL3
These segments are all flat that cover maximum address, so you do not need the "rest of memory" segments.
It's worth to note that if you plan to use syscall/sysret instructions, they require the descriptors comes in intended order.
Post Reply