2015-11-30 7 views
2

я реализую что-то очень похожее на упрощенным ОС, но я изо всех сил, чтобы понять, что системные вызовы на самом деле:
Прежде всего - в технологической системе, какой поток делает обычно * выполнить процедуру прерывания (syscall) - один из потоков ядра или поток пользовательского пространства, заданный временными привилегиями и обычным адресом?
Каким будет механизм syscall, реализованный в пользовательском пространстве - выполняет ли одно из следующих действий примерно то, что происходит под капотом?
Реализация A:Как системный вызов обычно реализуется

//equivalent to assembly 
//MOV EAX sys_call_no 
//INT 0x80 
void* interrupt(int service, void* args) 
{ 
    return kernel::int_vector[service](args); 
} 

Реализация B:

//equivalent to assembly 
//MOV EAX sys_call_no 
//INT 0x80 
void* interrupt(int service, void* args, void* ret) 
{ 
    kernel::intr_queue.push_back_syncd(interrupt_context(){kernel::int_vector[service], args, ret}); 
    waitForServiceCompleted(); 
    return ret; 
} 
//in kernel thread 
while(true) 
{ 
    while(!intr_queue.isEmpty()) 
    { 
    auto context = intr_queue.pop(); 
    context.ret = context.func(context.args); 
    notifyDone(); 
    } 
} 

C: Я не понимаю, это вообще - она ​​работает совершенно по-другому.
* от обычно я имею в виду наиболее распространенные в настоящее время настольных систем, таких как окна 7/8 или последнего дистрибутива Ubuntu
примечание: жаль, если это не правильный сайт SE разместить этот вопрос - Прокомментируйте, пожалуйста, мне, чтобы переместить его

ответ

2

Реализация A, как правило, работает. Операционные системы в основном используют свои собственные потоки только для задач, которые не связаны с непосредственным ответом на конкретный запрос процесса. Когда процесс выполняет типичный системный вызов, этот поток переключается на стек ядра и начинает запускать код ядра в контексте ядра.

+0

Спасибо, что нет ничего похожего на syscall queue? (даже не для чтения с жесткого диска?) Я был озадачен тем, как аргументы syscall, хранящиеся в регистрах, были переданы в ядро, это объясняет, что довольно хорошо, что поток просто сохраняет их. – wondra

+1

@wondra Там определенно находятся очереди запросов различного рода. Но системный вызов, подобный этому, разбит на части. Во-первых, запрос выдается. Затем, если и только если необходимо, поток будет ждать в пространстве ядра для завершения запроса. Например, прерывание диска может обслуживаться в любом потоке, который он ударил, а затем он может освободить поток, временно заблокированный в пространстве ядра из-за системного вызова 'read'. Это поддерживает системные вызовы, которые не нужно блокировать как можно дешевле. –

+0

Итак, они заблокированы * внутри * пространства ядра? Полезно знать - это действительно очищает вещи. Но возникает другой вопрос, если другой поток получает прерывание диска, какой механизм уведомляет исходный поток? Посмотрите на владельца дескриптора дескриптора файла, и если он заблокирован, он просыпается (что также подразумевает наличие мьютекса для этого в PCB)? – wondra

Смежные вопросы