OSDev.org

I've done some searching and can't find a general discussion or page regarding different techniques of implementing a kernel API, either on the web, the forums, or on the Wiki. Perhaps I'm using the wrong search terms, but I come up with very specific results (usually relating to Windows or Linux).

How should it be done? How can it be done? What type and scope of functions should it implement?

Should processes use things like call gates to access functions in the kernel or use a defined location in memory of a table to use as locations of function to call? Should they use some sort of RPC calls to accomplish this? What are the trade-offs of the different methods?

I'm sure the answers to these questions differ depending on the needs of the OS, the needs of the applications, and the capabilities of the hardware.

Please point me in the proper direction.

It sounds like you are looking for an ABI as well - tried System Calls?

As for the actual functions, I'd give some suggestons but I have no idea what you want of your OS, and my crystal ball was rather cloudy when I asked it...

Combuster wrote:It sounds like you are looking for an ABI as well - tried System Calls?

System Calls was the page I didn't find. Thanks!

Kernel API is implemented usign system calls.
You can reference it from book "Understanding the Linux Kernel 3rd Edition", chapter 10.
Or you can google "system call".

The Kernel API method is dependant on various factors as you have pointed out. A short list of these would include:

- Security
- Performance
- Thread safety
- Call Recursion
- User/Kernel Stack

I suggest drawing up a table of call mechanisms (e.g. Interrupts, Callgates, dynamic/static tables, system calls, etc.) and using the factors above and other factors that your OS's aim would include, table the benefits of each mechanism and make a decision using that.

zman97211 wrote:What type and scope of functions should it implement?

What type and scope of userspace programs should it support?

A standard C library requires something akin to open(), close(), seek(), write(), read(), remove(), rename() (although this can be done with copying-and-deleting, it's better to have a syscall for it IMHO), a function to exit from a process (_Exit()), a function to allocate a chunk of memory (sbrk(), mmap() etc.), and a function to return a chunk of memory to the OS.

This gives you the capability to have standard C-compliant userspace programs. I assume you will want that, at minimum.

From there, you start extending your kernel API according to the features you want to support. For example, if you want threads / process control, you need something akin to fork(), wait(), and getpid().

Keep in mind, too, that most systems provide a library of ordinary functions which make the actual system calls; the application programmer may be able to use the system call mechanism directly, but generally would use the userland-level library. This both simplifies the interface, and abstracts the system specifics (making both portability and changes to the system call mechanisms easier). The application libraries do not necessarily match the system calls, either; while some may be simple wrappers, others may perform various sorts of processing on the data in to and out of the calls (e.g., printf() generally only calls a string output after it's formatted), may specialize or simplify the interface in various ways, or even choose between different system calls or skip them entirely.

Thus, there can be a difference between the system call ABI and the actual API, if you are willing to go the extra mile for the user libraries.

The practical upshot of this is that from the perspective of most application programmers, the details of the system call mechanism isn't terribly important. It is very relevant to you, as the system designer and the author of the system libraries, but you don't want to predicate the design of the system call mechanism on application programmer convenience.

As Solar said, you will want to provide a certain number of primitives which can then be used for the actual API.