OSDev.org

samuelagm wrote: Just study some good C tutorials (just a basic knowledge of assembly language is required for now), then get Bran Kendrich's basic kernel with GDT, IDT,Keyboard driver ..

A note of 'Dissent':
'Bran Kendrich' is a wrestler. How is he supposed to write a kernel?

Brendan, is he tearing you?

Chandra wrote:

samuelagm wrote: Just study some good C tutorials (just a basic knowledge of assembly language is required for now), then get Bran Kendrich's basic kernel with GDT, IDT,Keyboard driver ..

A note of 'Dissent':
'Bran Kendrich' is a wrestler. How is he supposed to write a kernel?

Lol, good catch

gravaera wrote:PMM -> VMM -> Heap: PMM and VMM combine to provide page granular allocations.

Exactly. A user-space malloc() wouldn't need much more than that: A system call that allocates 1..n pages. (Think mmap().) Breaking down those memory areas into smaller blocks, handling the free-blocks-list(s) etc. is best done in userspace (so you don't have to cross into kernel space for every malloc() / free(), only in those cases where more memory is requested, or no-longer-used memory passed back to the system).

The kernel might have different requirements regarding the handling of memory (canaries? number of free-block lists? sizes of memory blocks?), or it might have the same, but the request for a lump of memory (usually page-sized) is common to both the user-space malloc() and whatever the kernel does. So it makes sense to make that a seperate function which is called by both clients. But you aren't aware of that when you start at the bootloader and think no further than the next step.

I've seen more than one project lumping together some haphazard all-in-one memory handling in a kernel function called "malloc()", then getting confused when the subject of a user-space malloc() first comes up, trying to pry the existing kernel malloc() apart to isolate a proper interface for said system call (or ending up having two completely different memory handlers, one for kernel and one for user space). All the while getting confused as hell in their communication because they're facing two malloc()'s in their code base.

That's why my suggestion is to think things over before you start, getting a rough sketch of where you want to end up with your design (even if you don't have the knowledge to get the details right - revising this sketch is iterative). And not calling your kernel funktion malloc(). Call it kmalloc() if you want, to herald that it's much like malloc(), but not the same.

I'm not sure I fully understood the rest of your post, with sound libs and GFX API libs and all that: a kernel certainly won't be exposing its internal heap's malloc() entry point to userspace.

No, it would expose it's AllocMemPage(), or whatever that function is called. If the author thought of isolating that functionality in a seperate function instead of hiding it in the guts of his kernel's malloc().

Also, there really is no trap to fall into in realizing that you've been writing code that copies buffers from one location to another in several places, and that this would be better done with a memcpy() implementation. So you write memcpy, and replace those occurences, then move on.

I prefer to minimize the going-back to older code where possible.

I'm not very sure whether or not I'm the one misunderstanding the OP's question, and in the end it doesn't matter anyway, since both posts just gave suggestions.

No problem. Just trying to make clear what I was talking about.

thanks really you helped me a lot by giving me those advice now i m confident and i sence that i can do it... really guys thanks for the help.

if i have some trouble in code can you explain me how to do it?

Cchedy wrote:thanks really you helped me a lot by giving me those advice now i m confident and i sence that i can do it... really guys thanks for the help.

if i have some trouble in code can you explain me how to do it?

Unless it's something really esoteric or which totally lacks documentation, there is no need to explain "how" to do it. Most existing documentation outside of tutorials merely tells you what needs to be done, and it's up to you to decide the best way to do it.

thank for the link samuelagm it 's very helpuful...
that's explain all what i need to...it's much better .