OSDev.org

Hi to all,

After kernel development most of us think about support for user level applications that will make the operating system useful.
For that,system calls (more specifically user level API calls) should be designed.
The problem that arises is what API to include and which not to include.
Some of us do not even know where to start nor which function calls to implement.
I will like us to have a look at this issue and list (post here) the API calls that we think can be usefull and even useless to implement for user applications.
People then could choose from the list the api calls that suit them and their operating system.
It may seem somehow stupid as idea,but ask application developpers how they fell when they want to maybe write some application and a function to perform some task is not found in the API......(you may ask also to their keyboard,mouse,or spouse ).
Thanks to all.

Hi,

Have a look > here < for a list of linux calls. Ralph Brown's Int List also has details of system calls from various systems, including DOS extenders as and suchlike (as well as full OS's).

I know I haven't exactly given you any idea of wrapping these with an API, but reading what existing OS's do should be a good start.

Cheers,
Adam

Hi,

my list of essential system calls is below. Note that functions on the same line can sometimes replace each other. E.g. mremap() can be used as mprotect() or free().

Kernel level stuff:
- alloc(), free(), sbrk(), mmap(), mprotect(), mremap()
- thread_create()
- fork() + exec()
- IPC: pipe(), grant(), sendmsg(), recvmsg(), kill(), waitpid(), signal()
- sleep(), yield(), alarm(), time()

Drivers:
- VFS: chdir(), open(), read(), write(), seek(), unlink()
- Network: socket(), listen(), bind(), get/setsockopt()
- I/O: select(), poll(), epoll(), dup(), close()

I'm not saying you need those exact API calls but you need something that provide their functionality in some way. For example there could be a service that sends an IPC reply after a given time and IPC messages could always start a new reciever thread in your application. That would give you thread_create() [message to yourself], recvmsg(), signal(), alarm() there right on the spot.

MfG
Mrvn

Depending on how your os is structured and what level of abstraction your kernel provides you might also want;
ShareMemory(), SendData(), RegisterWindow(), etc.

I prefer the "keep-it-simple-and-flexible" Unix method by some OS's like Windows have thousands of system calls.

ProgressGirl wrote:Depending on how your os is structured and what level of abstraction your kernel provides you might also want;
ShareMemory(), SendData(), RegisterWindow(), etc.

I prefer the "keep-it-simple-and-flexible" Unix method by some OS's like Windows have thousands of system calls.

For me ShareMemory() is the grant() call I mentioned. In mikrokernels it is often referet to as granting other processes access to your memory, hence grant().

Also SendData() is sendmsg(). For small data I use registers only. For large data I combine grant() with sending a pointer. The advantage of shared memory for sending data is of course not copying the pages.


I also prefer "keep-it-simple-and-flexible". Although I go to the more extrem of mikrokernel or nanokernel. Unix has way to many syscalls, many of which can be provided perfectly by services that run outside the kernel. My kernel only handles processes, memory and IPC. I think the minimum number of syscalls you can get away with comfortably is 6 as seen in L4 iirc.

MfG
Mrvn

Some people who have seen some of my posts on GUI will say i am obsessed,but i will still ask the question:
What about GUI functions,i have not seen someones posted here.....
Thanks to all.

For me the GUI is an own process to which other process' might send msg's to draw a window etc...
If your GUI is implemented in your kernel then you should have special syscalls

Hi,

My UI will be a separate process too. The video driver will be a normal driver which is contained in the file system. This driver will be locked by the UI, which is started by the kernel.

The UI will then accept calls via a separate interrupt handler, operating in ring 3. In other words, I will have kernel using SYSCALL / SYSENTER and the UI using INT XX. Of course, I will have an appropriate API to go with this.

Although I have not got to implementation stage, I think this should be quite workable.

Cheers,
Adam