Okay uhm, a note to KemyLand, I think you should not give your idea up just because someone on this forum said it's not a good idea. You should at least wait for some other opinions, because not everyone on here knows everything best
Well, as Combuster already pointed out, a
blank toolchain can compile C code that can be executed. By blank I mean a set of binutils & gcc compiled for a specific target platform & architecture without having a C library or anything else added. This is essentially everything you need for the kernel itself. With this in your hand, you have the freedom to do whatever you want with your memory.
Now you have to make a distinction: kernel space and user space. I don't know how familiar you are with malloc, so I will give a short overview about whats different there.
In the userspace malloc is (usually!) just an algorithm that uses some way to interface with the system to first find out which memory areas it can use, and then manage that area of memory. If you port a C library like newlib to your userspace, there will already be an implementation of malloc. As I said, malloc needs some way to interface with the system to get it's usable memory area:
sbrk is one of the functions that malloc uses to ask the system 1. where this usable memory lays and 2. to extend or shrink this memory. There are also other malloc implementations that for example use the
mmap which is a bit more complex and relies on yet other system functions. So malloc is absolutely nothing but a function that manages a chunk of memory that the kernel told the process that it could use.
In the kernelspace malloc (usually!) is also just an algorithm, but the difference is that the kernel itself knows what areas of memory it can use for its own heap, so it doesn't have to ask anyone for it. For example my kernel is a higher half kernel, and has a it's heap in the higher half. Then theres a simple malloc/free implementation that just manages the memory inside that heap. If the heap runs out, then theres an
extendHeap function that makes that heap bigger, so malloc doesn't fail.
Note: Even if this is the most common case, malloc and free could do something completely different in both spaces, the only thing thats important is that it does what it's standardized for.
So what I want to say is basically: it is absolutely okay to create any kind of memory management in your kernel, it's perfectly okay to write something like
gcmalloc that has some kind of garbage collection algorithm in the background. The only thing you have to consider is if it makes sense to do it, if you have performance improvements, it makes your code simpler or whatever is necessary to fulfill your needs.
Greets, Max
EDIT:DaemonR wrote:
Not lies, any person who's ever used C knows you don't have to include any extra libraries to use malloc
Please man, check your stuff... "Normal" developers usually only use toolchains that are made for
their specific system and that
already contain a C library.
malloc is
usually part of the C library, but not necessarily. If you make a
OS specific toolchain for your userspace, what you really should, there will be NO malloc until you bring something in - like newlib - that provides an implementation for exactly this feature. I think you shouldn't feed new users on this forum with wrong information.