Memory manager

[carbonBased]

malloc and free are not usually part of the kernel

rather they are part of the user library (which is linked with the application at compile time)

Indeed, but some OSs (such as mine) also include a malloc and free implementation for the kernel -- a kmalloc() and kfree(), if you will.

It makes kernel development easier, in my opinion, when using things that don't necessarily fit well into a page allocator (dynamic lists, mutexes, semaphores, messages, etc).

for me (currently) i have no malloc/free for my kernel (most structures are 4k -- a complete page)

Indeed, and I think a lot of microkernels continue on this route and have no kmalloc/kfree implementation. Personally, I find this limiting, though... I like everything to be dynamic and easy to manage. To do this, I make us of a lot of lists -- and sometimes even hash tables and binary trees -- in my kernel. These things (I find) are easier to develop with a byte allocator (but, of course, can be implemented without).

JAAman, just curious as to how you maintain some of these things that I maintain via lists-like structures... for example, your active task list. I assume you align your task structures such that they fit evenly into a page? Or another method?

Cheers,
--Jeff

[mrkaktus]

carbonBased: You have micro or monolith kernel ?

For eg. I am writing a micro-kernel and putting everything to sub-systems in DPL3 where I have byte granularity alocation (also sub-system ). So in Kernel I have only 4kb granularity mm, IPC create link, IPC destroy link, and everything else (also multitasking) is in DPL3 (working on that now but there is a small part to finish :]). So I think you can write kernel easy without byte granularity allocator.

[JAAman]

actually, my current design is somewhat monolithic

i recently (over a year ago now) restarted my OS, and havnt had much time for actual coding, but there are aspects of my design which are becoming very clear, but others are not yet

as for my task list for my schedular, that is something i have been putting thought into, and i cannot design my list structure until i figure out how i will design my schedular, but it will definately fit into page alignment (one idea, is to make the active task list, simply a list of pointers -- pointing to process tables (which can be larger -- 4k each is an idea), the list itself will then be smaller and easily page aligned) but at this time i dont have any specific details worked out as im more conserned about my schedular design right now (how to manage priority levels, blocking, etc) then i will design my list management on that

one unusual thing about me, is i like to have absolute control over my code and design (which is why i like ASM over C, and much prefer NASM to GAS -- GAS will freely 'optimize' your code if it thinks you arnt looking, which to me, defeats the purpose of useing ASM

[carbonBased]

carbonBased: You have micro or monolith kernel ?

For eg. I am writing a micro-kernel and putting everything to sub-systems in DPL3 where I have byte granularity alocation (also sub-system ). So in Kernel I have only 4kb granularity mm, IPC create link, IPC destroy link, and everything else (also multitasking) is in DPL3 (working on that now but there is a small part to finish :]). So I think you can write kernel easy without byte granularity allocator.

My OS is a microkernel. Or at least will be. There are separate driver servers, etc, currently... however, they all reside in ring 0, for the time being. Lazyness, on my behalf

I do agree, with thought, you can fit all things into 4kb pages quite well. But for myself, the kernel manages a hierarchical tree of driver servers which was easier for myself to implement with a kmalloc()/kfree() implementation. I also use sorted linked lists of task structures (which do not align well into 4kb sections -- although could, I suppose) in my scheduler.

In any event, I figure it's simply a personal choice. While kmalloc() and kfree() might add some processing overhead, and perhaps a little bit of memory overhead as well, for me, the overhead was worth it in development ease (I also feel the overhead is negligable)

Cheers,
Jeff