OSDev.org

Practically all OSes use paging over segmentation. That means they get rid of the segmentation as much as they can, by loading 4G selector into all segments.

And of course, you'll have to set your own GDT because GRUB is not guarantueed to leave you one, and several system functions will still need the GDT to reload segments (like interrupts and friends)

Not to mention not setting your own GDT means adding things like TSSs or userland selectors will be quite difficult

To: JameM
About: my post on Tue Sep 23, 2008 8:32 pm

As you said, all segment are set to be the same. Ok, and what about esp? 0xffffffff to 0????? is not a risk????

The stack segment is set to the same as DS - base 0, limit 0xffffffff.

InsightSoft wrote:As you said, all segment are set to be the same. Ok, and what about esp? 0xffffffff to 0????? is not a risk????

You are quite right to worry about the risk here and if the x86 only used segmentation, you would not do this.

Fortunately, paging negates this. You will eventually have a setup where the page immediately below your stack is not present. This will mean that if the stack overflows, you will get a harmless Page Fault Exception rather than overwriting your heap.

Cheers,
Adam

about my problems: all solved... gdt, idt, c code ...all is working FINEEEEEEEEEEEEEEEEEEEEEEEEEEE! (thanks you guys)

Now I have another question: I load my kernel to 9000:0000 using 0x13 disk function, taking advantage while in rm (16 bit code)...
now, how can load from disk, to the 'deep water' (high memory)??? the same 0x13 function?

AJ wrote:

InsightSoft wrote:As you said, all segment are set to be the same. Ok, and what about esp? 0xffffffff to 0????? is not a risk????

You are quite right to worry about the risk here and if the x86 only used segmentation, you would not do this.

Fortunately, paging negates this. You will eventually have a setup where the page immediately below your stack is not present. This will mean that if the stack overflows, you will get a harmless Page Fault Exception rather than overwriting your heap.

Cheers,
Adam

Ok... I see... (thanks)

InsightSoft wrote:about my problems: all solved... gdt, idt, c code ...all is working FINEEEEEEEEEEEEEEEEEEEEEEEEEEE! (thanks you guys)

Now I have another question: I load my kernel to 9000:0000 using 0x13 disk function, taking advantage while in rm (16 bit code)...
now, how can load from disk, to the 'deep water' (high memory)??? the same 0x13 function?

There are several threads about this - IIRC it's either unreal mode or jumping back and forth between PM and RM, using int 0x13 in RM to transfer a sector to somewhere <1MB, then going to PM to copy that >1MB, repeat...

JamesM wrote:

InsightSoft wrote:about my problems: all solved... gdt, idt, c code ...all is working FINEEEEEEEEEEEEEEEEEEEEEEEEEEE! (thanks you guys)

Now I have another question: I load my kernel to 9000:0000 using 0x13 disk function, taking advantage while in rm (16 bit code)...
now, how can load from disk, to the 'deep water' (high memory)??? the same 0x13 function?

There are several threads about this - IIRC it's either unreal mode or jumping back and forth between PM and RM, using int 0x13 in RM to transfer a sector to somewhere <1MB, then going to PM to copy that >1MB, repeat...

What about creating a descriptor (16bit opcode) to point to 16 bit code of interrupt (taking from IVT)... and then use it on PM? what about?

InsightSoft wrote:

JamesM wrote:

InsightSoft wrote:about my problems: all solved... gdt, idt, c code ...all is working FINEEEEEEEEEEEEEEEEEEEEEEEEEEE! (thanks you guys)

Now I have another question: I load my kernel to 9000:0000 using 0x13 disk function, taking advantage while in rm (16 bit code)...
now, how can load from disk, to the 'deep water' (high memory)??? the same 0x13 function?

There are several threads about this - IIRC it's either unreal mode or jumping back and forth between PM and RM, using int 0x13 in RM to transfer a sector to somewhere <1MB, then going to PM to copy that >1MB, repeat...

What about creating a descriptor (16bit opcode) to point to 16 bit code of interrupt (taking from IVT)... and then use it on PM? what about?

You'd be running 16 bit real-mode code in 32-bit protected mode. Think about it.

I will take a tour to the IIRC... So, the only way is:

1) goto RM;
2) run the code;
3) back do PM;
4) copy from Low memory to deep water;
5) Run code...

right?