OSDev.org

I nearly felt guilty posting two requests for help in a single day... but at least it gives the boards some life... i have watched them for ages and it's sad to see them become less and less used... and on to the point...

I have written an OS... it boots... it can setup protected mode... runs a shell, has a gdt, has interrupt handlers and has a C function in the memory manager called set_gdt_gate()...

My problem is in that function.. based on all examples and tutorials i have ever seen the GDT is a constant size (in this case a three member array) and the function won't create gdt entries past those three. With the IDT i was able to defien the standard 256 constant becaue i needed it all and it is not flexible... but i am having trouble implementing a system to expand the GDT...

i know this probably means should not be attemtping OS Development but i can't resist so any help would be greatly appreciated. It is one of those things that kept me up at night when i first started wondering how exactly the kernel took over PMode from the loader and now i am ready to try it i am stumped for ideas...

if you need a dynamically expanding GDT, just allocate a range for it and map memory when you need it. Or just allocate 64k the first time.

The alternative is to use a LDT.

Btw, I dont think this place is anywhere near dead.

Well perhaps dead was the wrong word... but it is all relative... and i remember it once being so much more... perhaps that it just my perspecive changing and not the sight though...

I considered declaring the entire limit size but wouldn't that be a little wasteful? Does anyone know of any common algorithms for expanding it or is it standard to prepare for the entire structure?

Well, out of laziness i did construct the gdt with the maximum size. Still its only 64k and what is 64k on 256mb of ram?. You could use only 4k (one page) which allows for 512 descriptors.

Actually, all I use is 4 entries for an unsegmented memory model. Its all I need. 5 including the null descriptor. If you want to support long mode and 16-bit apps as well, you'll need 13 descriptors at most: 3 (16,32,64bit) * 2 (ring 0, ring 3) * 2 (code, data) + 1 (null descriptor). Next to that you generally only need one call gate to the kernel to get things working.
But still, i have no idea how others have solved that.

Also, you can use call gates in the IDT instead of the GDT, and once again you can use paging to your advantage and not map parts of your gdt to physical memory.

writing and using a kmalloc and krealloc might do wonders too.

And by now i have run out of creative ideas. Make your choice, I suggest

Tyler wrote:I nearly felt guilty posting two requests for help in a single day... but at least it gives the boards some life... i have watched them for ages and it's sad to see them become less and less used... and on to the point...

We're on pace to have the single busiest month in the history of the site(5 years) and probably any OSDev site ever.

You can view the site stats here: http://www.osdev.org/stats/ The general upward trend in June was when I switched the site to PHPBB and MediaWiki. The other big spike happens on Oct 18 when we merged with Mega-Tokyo. The only dips in usage seem to match up to school schedules. Alot of people that frequent this board are in school so anytime school starts back up, or a school vacation first starts, or it's test time you can see slight dips in usage but the overal usage trend is climbing.

Edit: My old custom forum software from about 2 years ago made the site seem really busy because all the threads were displayed as an expanded tree list. There is too much traffic for that now.

Ahh well your numbers beat mine... i was basing mine on a spread of ten people people i know who use the site. They also thought it had died when they could no longer see any of the pages the old site linked too... This is why i took Mechanics with my Maths and try to pretend statistics don't exist

And if any one is interested i came up with a system which i have nearly finished bastardising. Combusters comments about paging the gdt seeemed pretty wasteful to me so i have converted an old compression system i once tried to place into a Multi-Compressor (Compressed each file with specific routines)

Basically i use a system of paging but instead of putting the page on disk i simply keep a record of what is missing so i construct the empty components virtually and waste niether memory or disk space.