A IPC Design

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Post Reply
nbdd0121
Member
Member
Posts: 60
Joined: Thu Jul 25, 2013 8:10 am

A IPC Design

Post by nbdd0121 »

I think that implementing multiple IPCs will increase the difficulty to program both for applications, drivers and kernel developers. Thus, I came up with a design that only one IPC is needed in the kernel space. The unit of this IPC is a 4K-page, and every IPC calls will transport several 4K-pages.
Here are some prototypes of syscall:
ssize_t send(size_t pid, size_t type, void* address, size_t size, size_t flags);
This syscall will send `size` pages from `address` of sender's virtual address to `pid` process, and the target process will be interrupted by the sending.

ssize_t register_handler(size_t type, size_t (*handler)(size_t pid, size_t type, void* address, size_t size, size_t flags))
Receiver will bind a handler to a corresponding `type`, and when sender send the message, the receiver will be interrupted as the same as a coming signal. The receiver can either receive the message or abandon it.

Flags:
Bit 0: senders' ability to read/write
Bit 1: receiver's ability to read/write
Bit 2: whether the page should be duplicated
Bit 3&4: target of sending: specified/self/all/all excluding self

It is just like a memory sharing system but added some feature of signal
User avatar
bluemoon
Member
Member
Posts: 1761
Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong

Re: A IPC Design

Post by bluemoon »

nbdd0121 wrote:I think that implementing multiple IPCs will increase the difficulty to program both for applications, drivers and kernel developers. Thus, I came up with a design that only one IPC is needed in the kernel space.
For performance reason, I think it's better to implement two IPC interface instead of one.
- send signal (pass with registers, the kernel may still need to store the registers value in intermediate memory, but application does not need to mess with allocating/mounting pages)
- send memory pages
nbdd0121 wrote:This syscall will send `size` pages from `address` of sender's virtual address to `pid` process, and the target process will be interrupted by the sending.
Why the target will be interrupted? I think it should be unblocked and rescheduled.
nbdd0121 wrote:

Code: Select all

ssize_t register_handler(size_t type, size_t (*handler)(size_t pid, size_t type, void* address, size_t size, size_t flags))
Receiver will bind a handler to a corresponding `type`, and when sender send the message, the receiver will be interrupted as the same as a coming signal. The receiver can either receive the message or abandon it.
This looks like C signal. IMO signal is more complex than a wait call in application programmer perspective, due to unpredictable code path, and generally result in heavy use of mutex.
Post Reply