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.
