OSDev.org

So as some of you that have been in the OS Testing forum know, I've been writing whitepapers online rather than extensively commenting my OS code as I used to. About an hour ago, I finished whitepapering the boot code all the way up through the automation of paging (19 whitepapers on a variety of topics) and I figure it's about time I get some feedback from some knowledgeable people so I can figure out what I need to improve, add or remove from them.

Therefore I'd appreciate it if some of you kind, generous people with time to waste would go to www.codezen.org/viridis/ and check out the whitepaper section. I hope that you either report your thoughts here or email me at [email protected]. Don't feel bad if you want to flame my @$$ either, I can take it (and I'll probably make better whitepapers for it too).

*KAPWING* I'm off to class.

wangpeng I had a quick look at your site, and at your source code and I must say it does look quite nice. I'm especially interested in your memory management routines. They seem complete enough for you to use, yet so much simpler looking that all the other monster memory managers I've had the misfortune to try and understand.

Glancing over the papers, they look not bad. Its nice to see people writing lots of good documentation - you can never have enough

Keep up the good work.

Fine documents.

Althou I find the concept of your heap management a bit confusing at a first glance. Have to read throu it once more, don't have sooo much time at hands at the moment.

Just try to keep the sentences short in some places.

BTW: are you using Hardware task switching or stack based task switching?

@IRBMe: Thanks alot.

@Beyond Infinity: Thank you too, I wish you could give examples of the sentences you consider too long though. As for task switching, I'm definitely using a stack based switching.

BTW, I can't thank Brendan enough. He helped me with some errors (as mentioned on the mainpage) and suggestions (like reentrancy protection).

As a note, I think four additional whitepapers have been written since the original post and while that's no big deal, three of them have to do with my highly controversial ::) ADST memory management system. Considering that I'm paranoid about its development and paranoid about writing them correctly, I'd like to call special attention to just those three papers (under the MM section of the whitepapers).

First one in ADST: 0xFFFFFFFC does not set the last two bits as you imply it does.

There is no way for the OS memory mapper to merge with previous segments, as you have no idea where its descriptor would start. You need a backpointer or something similar.

It's VERY uncommon to free integers from the middle of an array. Try freeing the entire array or speaking of entirely separate ints.

Just glancing over the code, my first guess is that you didn't test it thoroughly yet. Second thought is that you comment too little in the code. Don't overcomment either, most people can figure out what i++ is supposed to do. But please do, explain why you are looping and why you have certain things in there.

@Candy: I've tested it plenty. The 0xFFFFFFFC isn't supposed to set the last two bits, it's supposed to make sure that NOTENDOFHEAP is *un*set because that's the only bit that really matters. I realized that I typoed and am changing it, thanks.

As for combining with previous segments... it does it easy... read the free() paper.

I don't think I said that the example was an array of ints, I think I just said it was 4 ints making 16bytes... quote: "But say that we wanted to allocate memory for 4 integers (16 bytes)"

As for commenting of the code, the entire point of the whitepaper was to eliminate the in code comments to make it clean looking code and to break up the code later for exposition. Can you give me particular examples of a place that is lacking good explanation... then I can be more clear.

Quick reply, not much time:

As for combining with previous segments... it does it easy... read the free() paper.

OK, figured out how you free them. This method doesn't scale well.

Normal allocs are in O(n) in terms of finding a block large enough to use. Frees are in O(1) as the information for freeing and merging is all located there. In your algorithm they are both in O(n). The freeing-function must look through the entire list to find a block large enough.

Note: some algorithms have both in log(n), but there are few that are worse. F.I. best-fit with radix indexing (or whatever, keeping a list of pointers to the first 2^n + entry for 4<n<bitsize)
works in O(n/c) since it only has to find one that fits in a small section (and can be brought to O(1) even, but it then always takes a section too big) and freeing is in O(1) too. They are certainly better.

What are you trying to accomplish that the other methods can't do?

Candy wrote: What are you trying to accomplish that the other methods can't do?

Uhhh... nothing.... It's not supposed to be the fastest, it's not supposed to do anything that others can't do, it's supposed to be the simplest segment based mm possible. If it was really important, I'd use a bitmap or a more complex approach... right now simple is all I can say.

I mean, if it was necessary (like I really needed performance out of an OS that currently does nothing) I'd split the top 30 bits into 15 and 15, complicate the code into using that kind of backpointer, keep the resolution at an integer but limit the size of the heap to 32768 integers (128 k)... a size that will probably never be used anyway.

On the other hand, most of the stuff on the kernel heap will never be freed anyway (in Viridis at least), so we're talking like 2 to maybe 5 descriptors at once so (right now) scaling isn't an issue. If all the sudden I'm allocating and freeing giant chunks of memory all over the place then maybe a more complex memory manager is something to look into.

I never promise that Viridis will be the fastest or most innovative, but I try and make it the very simplest you can find, and in this case I think the memory manager basically fits the task.