Should RTL be shared between kernel and app?

[leledumbo]

When creating an OS, we need a RTL to handle some kernel related stuff (text mode printing, paging, etc) but also things that occurs in normal apps (standard printing, dynamic memory allocation, etc). Now, when we're ready to have apps running on top of our OS, should it use the same RTL used by kernel? Or is it better to have a separate one?

[AndrewAPrice]

In a single tasking system where applications have full access over the hardware they can. However, generally no.

There are parts you can share. For example, I use the exact same string class for applications and my kernel. You can share certain parts of code (to avoid writing the same thing twice) but you won't be able to use the EXACT same library on each sides.

Here are some examples:

text mode printing

The code for parsing text (printf) can be the same, however displaying it on the screen will depend on if the code to handle writing the text on the screen is in the kernel or it's own driver:
If your video code is in your kernel: No, your kernel's code wiil write directly to video RAM while you applications will use a system call to do so.
If you screen driver is separate from the kernel (e.g. in /dev/console): Yes, you will use near identical for writing to the device (though your IPC implementation will be different in kernel vs application).

paging

Allocating pages is something only the kernel should do. The kernel will call a large and complex algorithm to allocate a page, where as if an application requires a page it'll usually do a syscall!

dynamic memory allocation

Yes, you can generally share the same code. Though the code for requesting a new page will differ, see above.

It is usually a good idea to have an identical API (function names, classes, etc) for both your kernel and user libraries, since it'll lead to less confusion and make it a lot easier to move code between the two.