L4 and Fast Interprocess Communication

Подписаться 4,6 тыс.

Просмотров 14 тыс.

50% 1

cs4414: Operating Systems (rust-class.org)
Class 22: Microkernels and Beyond
Embedded notes are available at:
rust-class.org/class-22-microk...
Segment 3: L4 and Fast IPC
L4
Fast IPC
Tradeoffs in Microkernel Design
Benefits of Small Kernels
seL4

Наука

Опубликовано:

30 июн 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 8

@ingeralhaosului 7 лет назад

Hi, i do not understand why the kernel needs to copy the information 2 times, can't the kernel copy the information directly from task a's memory to task B's memory? Isn't allowing task a to copy to task b's memory dangeros, what if task a says it want to copy 1kb of information but instead makes a 2kb copy and intentionally messes up task b's memory? If shared memory is necessary is't it better for task a to create the shared memory and for task b to only receive access to it, or for the kernel to create a new memory space, copy the data into it and then give the memory space to process b?

@DavidEvans 7 лет назад

I'm not sure I understand the question, but I think the issue is that in order for Task A to send a message to Task B, it needs to go through the kernel since providing direct access to Task B's memory would be unsafe. To go through the kernel, Task A need to send a message to the kernel, and then the kernel sends a message to Task B. I think what you are suggesting is that instead of actually sending the full data in the message to the kernel, task A could just send a description of it (e.g., the start and end address in its memory space), so there is no need to copy the memory into the kernel, then the kernel would directly copy from task A's memory into task B's memory, only needing to make one copy. This makes good sense to me, and would be less expensive than copying the data into the kernel, and then the kernel copying it into task B's memory, when the data is large.

@user-vq2jt3rm5l 4 года назад

great lecture. thank you

@kayakMike1000 8 месяцев назад

Yeah... here's an idea. Ask the kernel to set up some memory that a producer can write to and a consumer can read from. The producer and consumer processes can work out some mechanism so the consumer process won't read until producer is done writing and the producer doesn't overwrite until the consumer is done reading. I think I will call this IPC mechanism something ironically funny or maybe just internal datagram protocol.... perhaps 9p?

@kayakMike1000 8 месяцев назад

Oh and the consumer never ever writes any data, unless it's just some flag to say it's done reading the data...