안녕하세요.

실컷 작성중에 다 사라져버렸네요@@

시스템콜은 svc라는 특수한 명령어를 이용해 user 에서 kernel로 진입해서 kernel 에 구현된 함수를 수행하는 것입니다. 그러므로 user mode에서 kernel mode로 변경되는 즉, context가 변경이 되어야 합니다. 이것은 현재 running 중인 process의 context를 저장하고 인터럽트가 수행되는 것과 유사합니다. 즉, 구현 나름이지만 인터럽트로도 구현은 가능할 것입니다. 하지만 일반적인 인터럽트라고 말하진 않습니다.  더구나 인터럽트는 언제 발생할 수 있을지 예측할수 없지만 시스템콜은 직접 이순간에 호출해야지 하고 호출하는 것입니다. 다만 공통점은 현재 context를 저장하고 다른 context를 수행한다는 것 뿐입니다.

일반적으로 software interrupt를 이용하는데 포괄적 개념으로 인터럽트라고 하지 저희가 일반적으로 말하는 인터럽트처럼 스케줄링 안되고 어쩌고..등과는 다릅니다. 인터럽트 보다는 exception이라는 용어가 더 맞을 것 같습니다. 

아마 x86도 비슷하겠지만 arm도 software interrupt를 위한 명령어 swi를 사용하는데 이게 호출되는 순간 user mode에서 kernel mode로 hw에 의해 변경이 됩니다. 이렇게 kernel mode로 변경이 되면 시스템콜 테이블에서 해당 함수를 찾아서 호출된 시스템콜에 부합하는 함수가 수행이 됩니다.

시스템콜이 인터럽트 처리 완료 후에 호출이 된다는 소리는 처음 듣습니다. 일반적으로 인터럽트는 kernel mode에서 동작을 합니다. 즉, 이미 user에서 동작 중이던 process는 이미 선점당한것이죠. user에서 시스템콜을 호출하면 바로 kernel mode로 변경이 되고 해당함수가 kernel mode에서 수행됩니다. 이 때 인터럽트가 발생하면 당연히 발생한 인터럽트에 해당되는 인터럽트 서비스 루틴이 수행될 것입니다.

시스템콜을 일반적 관점의 인터럽트(다른 프로세스가 동작하지 않는 상태)의 관점에서 보면 인터럽트가 아닙다. 단순히 exception 즉, 모드 변경의 관점으로 보는게 맞습니다. 그러므로 반응성이 느려지거나 하는것은 별개의 문제입니다. 잠시 삼천포로 빠지자면, 일반적으로 ISR(인터럽트 서비스 루틴)이 길어지면 반응성이 떨어지므로 최소한의 것만 ISR에 구현하고 대부분은 커널 쓰레드 등을 이용해 처리하도록 합니다. 

시스템콜은 unprivieged mode에서 privileged mode로 변경해서 kernel mode에서 함수가 수행되도록 하는 행위를 말합니다. 당연히 스케줄될수도있고 일반적인 인터럽트가 치고 들어올 수 있습니다.

프로세스(혹은 쓰레드)가 선점 할수도 선점될수도 있다는 말은 current task가 running중에 다른 task에게 뺏긴다는 것을 의미합니다. 일반적으로 a task가 돌고 있는데 a가 양보하지 않으면 어떻게 b가 돌 수 있을까요? 결국 인터럽트에 의해 b task가 깨어난다는 것을 의미합니다. 이때 a가 할당 받은 시간동안 동작한 후 b가 동작한다면 선점형이 아닙니다. 그런데 할당받은 시간을 다 사용하지도 못했는데 b가 실행이 되면 선점형이 되는 것입나.

리눅스 커널의 경우 a가 동작 중인데 인터럽트에 의해 b를 실행시키려 합니다. 이 때 선점형 리눅스가 아니면 커널은 인터럽트 처리 마지막에 b를 runqueue에 넣고 해당 인터럽트는 종료할 것입니다. 그리고 나서 나중에 a가 할당 받은 시간을 다 소비하면 다른 실행할 task를 선택할 것입니다. 이 때 타이머 인터럽트가 이용이 됩니다. 할당받은 시간이 다 소비될 때 타이머 인터럽트가 발생해서 다른 task를 runqueue에서 꺼내서 실행하는 것입니다.

그런데 선점이 지원이 되고 b가  a보다 우선순위가 높으면 최초에 b를 runqueue에 넣을 인터럽트가 발생하면 runqueue에 b를 넣고 인터럽트 처리 끝부분에 바로 b를 실행시킵니다.

인터럽트루틴에서 코드가 동작하면 반응성이 문제가 되겠죠 당연히 일반루틴과 구별이 되어야 합니다. 네스팅 인터럽트는 일반 스케쥴링과 다르게 분명한 한계가 있습니다.

주저리 주저리 적었는데 이해가 되셨는지 모르겠네요. 나름 최대한 간단하게 많은걸 생략하고 적었습니다. 이해가 안되시거나 제가 잘못 작성한게 있으면 답변 달아주세요

리눅스 공부한지는 얼마 되지 않았지만 제 생각에는 시스템콜이 인터럽트에 속하는게 맞는것 같습니다.

인터럽트는 크게 두가지로 나뉘는데요
첫 번째는 외부 인터럽트, Timer나 Keyboard등의 CPU가 아닌 외부의 하드웨어에 의해 발생하는 인터럽트입니다. 따라서 CPU의 클럭과 동기화되지 않으며 보통 예측 불가능한 경우가 많습니다.

두 번째로는 내부 인터럽트, 소프트웨어에 의해 발생하는 인터럽트로 Trap이라고도 합니다. 0으로 나누거나 Page fault등의 예외처리등에서 발생합니다. 프로그램 내부에서 발생하므로 물론 CPU클럭과 동기화되어서 발생하게 됩니다.

시스템콜은 Linux x86같은 경우 eax에 인터럽트의 vector number를 넣고 0x80 인터럽트를 호출함으로서 발생시킵니다. 그럼 시스템은 인터럽트 핸들러로서 시스템 핸들러 함수를 호출하고, 해당 함수에서 eax값을 참조함으로서 원하는 시스템콜 함수를 호출하게 됩니다. 따라서 인터럽트중에서도 내부 인터럽트로 보는게 맞지 않을까 싶습니다.

덧붙여서 시스템콜이 인터럽트라고 하더라도 복잡한 시스템콜을 만들 수 있을것 같습니다. 인터럽트가 발생하면 인터럽트 핸들러가 호출되는데 글에서 적으셨듯이 인터럽트 핸들러가 길어지면 반응성등의 문제가 발생합니다. 따라서 이를 선처리와 후처리로 나누어서 선처리에서 핸들러에서 반드시 해야하는 일을 하고 조금 지체되어도 되는 일은 후처리로 넣어서 인터럽트가 활성화되고 cpu가 여유가 있을 때 수행하는 것으로 알고 있습니다. 이에 관해서는 bottom-half나 태스크릿, soft irq등으로 검색해보시면 됩니다.

예를 들어 네트워크 패킷을 받는 인터럽트 핸들러를 구현한다면 선처리에서는 패킷을 받았다는 신호를 보내고 버퍼를 비웁니다.(버퍼 오버플로우 방지) 그리고 패킷을 처리하는 부분은 시간에 비교적 덜 민감하고 오래 걸리는 작업이기 때문에 후처리로 미루어서 처리를 하게 됩니다.

다만 실제로 시스템콜이 이렇게 선처리 후처리로 나누어서 구성하는지는 부정확하니 한번 찾아보셔야할듯 합니다.