Действительно ли системные вызовы «прерывают» ЦП так же, как это делают аппаратные прерывания?
Вы пытались запустить wine64? В моей среде я сделал:
apk update && apk add wine && ln -s /usr/bin/wine64 /usr/bin/wine
INT 0x80h— это старый способ вызова служб ядра (системных функций ). В настоящее время syscallsиспользуются для вызова этих служб, поскольку они быстрее, чем вызов прерывания.Вы можете проверить это сопоставление в таблице дескрипторов прерываний ядра idt.c и в строке 50 в файле irq _vectors.h .
Важным моментом, который, как мне кажется, отвечает на ваш вопрос, является заголовок последнего файла, где вы можете увидеть, как организованы запросы на прерывание (IRQ ).
This is the general layout of the IDT entries:
Vectors 0... 31 : system traps and exceptions - hardcoded events
Vectors 32... 127 : device interrupts
Vector 128 : legacy int80 syscall interface
Vectors 129... INVALIDATE_TLB_VECTOR_START-1 except 204 : device interrupts
Vectors INVALIDATE_TLB_VECTOR_START... 255 : special interrupts
На самом деле не имеет значения, с помощью электрических или программных средств. Всякий раз, когда запускается прерывание, ядро ищет его идентификатор в IDT и запускает (в режиме ядра )связанный обработчик прерывания . Поскольку они должны быть очень быстрыми, они обычно устанавливают некоторую информацию для обработки позже с помощью softirqили tasklet. Прочтите главу 2 (fast read... )из Ненадежного руководства по взлому ядра Linux
Позвольте мне порекомендовать также прочитать этот действительно хороший и исчерпывающий ответ на stackoverflow на вопрос Intel x86 vs x64 system call , где INT 0x80h, sysenterи syscallпомещены в контекст...
Я написал свою собственную (очень скромную и все еще находящуюся в стадии разработки )страницу самообучения о прерываниях и сигналах , чтобы помочь мне понять связь сигналов и ловушек с прерываниями (, например SIGFPE -разделить на ноль ).