Designing effective syscalls

[greyOne]

I'm slowly working my way towards user space, and at this point, I'm trying to plot out a good structure for my syscalls.
So far, my design covers

• Creating, handling and interacting with pipes
• Requesting system information (free memory, total system memory, etc.)
• Mapping and unmapping pages
• Process and thread handling (Including requesting global information for process count, etc.)
• Syscalls required by Newlib

Is there any blatant detail or section I've overlooked?

There other little thing that's bugging me relates to drivers and the VFS.
Implementing Newlib's required syscalls creates a structure (at least, that's what I ended up with)
Where Newlib requests file information and operations from the kernel space.
However, I intent to put device drivers and the VFS into userspace.

Inter-process communication is a way of going about doing this, but I'm wondering if there's a better approach.
In fact, if there's any good reading material for this field, that would be best.

[Brendan]

Hi,

• Syscalls required by Newlib

However, I intent to put device drivers and the VFS into userspace.

In this case, I think it's a mistake to assume that the functions required by Newlib are syscalls and not some sort of lower level library in user-space.

For a simple example, newlib might have a "fopen()" function that calls "open()", and "open()" might be another function in another library that sends an "open_request()" message to the VFS and waits for an "open_reply" message to be received from the VFS; where the kernel does not provide an "open()" syscall but only provides syscalls to send and receive messages.


Cheers,

Brendan

[greyOne]

Hi,
In this case, I think it's a mistake to assume that the functions required by Newlib are syscalls and not some sort of lower level library in user-space.

For a simple example, newlib might have a "fopen()" function that calls "open()", and "open()" might be another function in another library that sends an "open_request()" message to the VFS and waits for an "open_reply" message to be received from the VFS; where the kernel does not provide an "open()" syscall but only provides syscalls to send and receive messages.


Cheers,

Brendan

Hmm, yes. That makes quite a bit of sense actually.
It's times like these when I'm glad I setup a strong set of IPC procedures early on.