Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Yes, I'm sliding back into OS dev again after quite a while just absorbing information and not otherwise being motivated. I've decided to become one of the brave souls doing a kernel in C++ as I've just become way too used to its extra friendliness and don't want to have to debug problems caused by slight syntax differences with C. Anywho, I just need to ask if the STL is ok to be used in a freestanding type environment? The OSFAQ mentions that the template code doesn't require extra support, but I don't know what other special stuff the STL uses that might exclude it, like exceptions or somesuch.
On second thoughts, of course it will use exceptions won't it?
Edit:
Gah, ok, linked lists and dynamically sized arrays... They will obviously need to allocate memory to use for stuff, which doesn't help me too much when I want to use them in my memory manager, lol. Luckily I have a plan The above question still applies though, once I can hook the new/delete operators up to my memory-manager-in-progress
Using the STL verbatim should be a problem, since it sort of completes the full runtime environment which should be larger than your kernel. You can use bits and pieces of it though, as long as you know what they do.
I believe exception use in the STL is optional, but that the alternative is pretty cruddy compared to exceptions.
When coding your own MM stuff, you could talk to Zeii, he's been chatting with me on ICQ for some days about it now. He should be able to explain the Buddy algorithm pretty clearly now
At the moment I'm just working on a simple linked-list based physical memory manager. It has a list of allocated regions of memory and a list of free regions of memory (basic optimisation of the lists can be carried out while allocating/freeing, but I aim to have a low priority background thread doing extra work on the lists eventually). These lists are made up of a pool of region descriptors, which is where I hit my first problem. How can you allocate memory for more when you've just run out of them to organise your allocations with? The solution was fairly obvious, when you get down to your last few then do a quick diversion to allocate some more while you still can. The occasional allocation will be a few microseconds slower for whoever attempted it, but I don't think it'll be an issue really (especially compared to scanning the list in the worst case of it being really fragmented after repeated allocating and freeing).
Now I just need to figure out how to keep track of what descriptors aren't being used in a sane way... Without optimising the list it's easy as once they're used they will stay used. It'll be the task of the optimisation code to make sure the used ones... *idea strikes mid-sentence* They all have a 'next' pointer of course, have a 'free descriptors' list made of all the ones that aren't in use. Problem solved for the mere cost of a single extra pointer to keep track of the first free descriptor. ;D
This code is of course fairly naive, with no concept of colouring, cache lines, or other such concepts, but it'll work as a simple one for now.
The above question still applies though, once I can hook the new/delete operators up to my memory-manager-in-progress
