인터럽트 벡터 테이블에만 추가되지 않고 시스템 호출 테이블이 있는 이유는 무엇입니까? 여기서 디자인 선택을 이해하지 못합니다. 이벤트 구별 성능이 향상된다면 시스템 호출은 왜 안 될까요?
답변1
나는 몇 가지 이유로 i386의 시스템 호출에 단일 인터럽트(0x80)를 사용하는 역사적 배경을 조사하지 않았습니다.아니요각 시스템 호출에 대해 별도의 소프트웨어 인터럽트를 사용하십시오.
- 소프트웨어 인터럽트 수가 제한되어 시스템 호출 수가 제한됩니다(x86에서는 다른 목적을 위해 많은 인터럽트 설명자 테이블 항목이 필요합니다). 이제 소프트웨어 인터럽트를 사용하는 대부분의 아키텍처가 지원할 수 있는 것보다 더 많은 시스템 호출이 있습니다.
- 상당수의 아키텍처에는 소프트웨어 인터럽트(또는 이에 상응하는 항목)를 사용하지 않는 전용 시스템 호출 명령어가 있습니다. 여기에는 x86-64가 포함됩니다.전용
SYSCALL명령어가 소프트웨어 인터럽트보다 더 빠른 시스템 호출 액세스를 제공하는 경우.man 2 syscall각 아키텍처에 대한 시스템 호출 규칙에 대한 세부 정보가 제공됩니다.
ARM/OABI 아키텍처의 세부 사항을 살펴보면 시스템 호출 번호가 명령어에 인코딩되어 있기 때문에 인터럽트 테이블이 사용된다고 생각할 수 있습니다.해당 지침고정된 소프트웨어 인터럽트가 실행되고 인코딩된 숫자는 무시되며 시스템 호출 처리기는 명령어 자체에서 숫자를 검색합니다. EABI는 캐시 오염을 초래했기 때문에 이 접근 방식을 포기했습니다(최신 ARM CPU에는 별도의 명령어와 데이터 캐시가 있음).
답변2
먼저 x86(-64)을 지원합니다.256개 항목 인터럽트 테이블, 그 중 일부는 실제 하드웨어 인터럽트에 사용됩니다. 처음부터 계산매뉴얼 페이지는 syscalls(2)여기에 있습니다, Linux에는 400개 이상의 다양한 시스템 호출이 있습니다. 모든 아키텍처에 존재하는 것은 아니지만다른 목록, x86-64에는 314개의 서로 다른 시스템 호출(0~313)이 있습니다. 따라서 적어도 x86 기반 Linux의 경우 각 시스템 호출에 대해 서로 다른 인터럽트 번호를 예약할 방법이 없는 것 같습니다.
물론 x86이 유일한 아키텍처는 아닙니다. 다른 것들은 사용 가능한 소프트웨어 인터럽트가 더 적거나 하드웨어 인터럽트와 별도로 시스템 호출 경로가 완전히 다를 수 있습니다. 실제로 최신 x86(-64)에는 이미 다음과 같은 별도의 경로가 있습니다.SYSCALL 및 SYSENTER 명령어:
SYSENTER/SYSEXIT 명령(및 AMD의 동등한 SYSCALL/SYSRET)은 커널에 대한 빠른 액세스를 제공하여 인터럽트 오버헤드를 방지합니다.
커널에 대한 단일 진입점만 사용하는 또 다른 가능한 이유는 특정 시스템 호출과 관계없이 사용자 공간/커널 전환과 관련된 강제 배열 때문입니다. 일부 상태를 저장해야 하거나 스택을 전환해야 할 수도 있습니다. 이러한 작업은 아키텍처 및 시스템 설계의 특정 기능에 따라 달라지지만, 이러한 작업을 수행해야 하는 경우 한 곳에서 완료하는 것이 더 쉬울 수 있습니다. (특히 이러한 낮은 수준의 작업은 새 컨텍스트에서 함수 호출이 이루어지기 전에 가장 먼저 수행되어야 할 수 있기 때문입니다.)
위 내용의 대부분은 추측에 불과합니다. 저는 x86 이외의 아키텍처(범용 운영 체제를 실행하지 않는 일부 아키텍처 제외)에 전혀 익숙하지 않으며 Linux 시스템도 본 적이 없습니다. 호출은 매우 엄격하게 구현되었으며 다른 작업 시스템은 말할 것도 없습니다. 더 낮은 수준의 세부 정보가 필요하면 다른 사람이 제공할 수 있기를 바랍니다.