목차
시스템 콜과 API / ABI 는 관계성이 높기 때문에 같이 포스팅을 진행하였다.
시스템 콜 (System call)
운영 체제의 커널이 제공하는 서비스에 대해, 응용 프로그램의 요청에 따라 커널에 접근하기 위한 인터페이스
OS의 보안 구조로 최심부에는 커널모드;Kernel mode가 최외곽에는 사용자 모드;User mode가 존재하게 되는 이중 구조를 가지는데 사용자가 커널의 기능을 사용할때 시스템 콜을 통해야지만 사용이 가능하다.
따라서 시스템 콜의 기능은
- 사용자 모드의 응용프로그램이 커널의 기능을 사용할 수 있게 한다.
- 사용자 모드 -> 커널 모드
- 커널 모드 -> 사용자 모드
API는 응용프로그램 인터페이스 ABI 는 기계값 수준에서의 응용프로그램 인터페이스를 뜻한다.
여기서 API와 시스템 콜의 대해서 살펴보자면
API stability guarantee(API 안정성) 와 Portablility(이식성) 인데 쉽게 말해 System call, 즉 호출 인터페이스는 각 운영체제 마다의 표준 규약에 맞게 설계되어 있기 때문에 유저 어플리케이션의 버전 등의 관리와 이식성을 보장하여 주기 때문에 시스템 콜이 이러한 이식성을 보장한다는 것이다.
예로 들어 리눅스의 경우 POSIX라는 규격을 따르고 있는데 이는 [Portable Operating System Interface uniX] 으로서 유닉스의 API 규격으로 리눅스는 유닉스와 개발에 관계가 없지만 POSIX 규격을 따르고 있기 때문에 리눅스는 유닉스의 호환 체제라고 볼수있다.(완벽히 호환되지도 않고 제공하지 않는 것도 있지만 규격을 따르고 있다. 포스팅예정) 윈도우 같은 경우는 WSL이라고 [Windows Subsystem for Linux] 이라는 리눅스를 기반으로한 가상 머신을 탑재하고 있다.
WSL에 대하여 자세히 기술해놓은 블로그 (외에도 수준 높은 글들이 많다)
시스템 콜의 종류에 대한 자세한 나열
- 프로세스 컨트롤
- 프로세스 생성 및 종료
- 메모리에 로드, 실행
- 프로세스 속성 값 확인, 지정
- wait 이벤트, signal 이벤트
- 메모리 할당
- 파일 메니지먼트
- 파일 생성, 파일 삭제
- 열기, 닫기
- 읽기, 쓰기, Reposition
- 파일 속성 값 확인, 지정
- 디바이스 매니지먼트
- 디바이스 요청 및 해제
- 읽기, 쓰기, Reposition
- 디바이스 속성 확인, 지정
- 비 물리적인 디바이스 해제 및 장착
- 정보 관리
- 시간 확인, 시간 지정
- 시스템 데이터 확인, 지정
- 프로세스, 파일, 디바이스 속성 가져오기
- 프로세스, 파일, 디바이스 속성 설정하기
- 커뮤니케이션
- 커뮤니케이션 연결 생성 및 삭제
- 메시지 송신, 수신
- 상태 정보 전달
- remote 디바이스 해제 및 장착
- 보안
- Permission 획득
- Permission 설정
응용 프로그래밍 인터페이스 (API)
코드 레벨에서 다른 소프트웨어와 통신하는 인터페이스를 정의한다.
위 사진을 보게 되면 Computer game 같은 기능, 프로그램과 라이브러리끼리의 인터페이스 역할을 하고 있는것을 알수 있다. 편하게 생각하면 어느 운영체제에서 지원하는 라이브러리와 기능과의 연결을 구현해놓은 코드 덩어리 라고 생각하면 쉽다. 이는 미리 이식이 가능하게 프로그래밍을 해놓았다고 생각하면 된다.
사용자가
따라서 프로그램을 제작시에 기반하는 운영체제가 지원하는 API를 기반으로한 라이브러리를 통하여 코드를 짠다. (이렇게 하는 편이 설계, 제작, 관리에 용이 하기 때문이다.)
응용 프로그램 이진 인터페이스 (ABI)
기계 수준에서 바이너리 프로그램와의 통신하는 인터페이스를 정의한다.
위의 API SCI Kernel 과의 관계에서의 사진에서 보면 API는 라이브러리와 어플리케이션의 인터페이스임을 알수 있다. 이와 비슷하게 ABI 는 라이브러리와 커널, 즉 운영체제와의 인터페이스라고 생각하면 존재 위치를 알수 있다.
위의 API의 에서 보면 Portability 이식성에 대해 설명하였고 이 이식성에 따라 사용하기에 적합한 API인지 구분이된다고 했었다. ABI 에서는 Compatibility(호환성) 에 따라서 프로그램의 사용가능 유무가 판별이 되는데 예로 들어서 맥 OS 에서 Window의 응용프로그램을 실행하지 못하는 이유는 ABI의 호환이 되지 않기 때문이다.
API에서 정의된 함수에 어떤 인수를 전달하는지에 대한 정보가 ABI 를 통하여 레지스터나 스택등에 인수가 전달되고
API에서 라이브러리의 함수를 정의하면 ABI는 라이브러리의 내용이 파일 내부에 저장되는 방식을 정의하고 라이브러리가 쓰인 프로그램에게 필요한 파일을 검색하고 찾아준다.
따라서 ABI는 기능적으로는 작동방식이라고 말할수 있다.
만약에 시스템의 모든 곳에 동일한 ABI방식을 적용하면 어떨까? 그럼 모든 프로그램은 라이브러리 파일의 종류와 관계없이 작동이 가능하게 된다.
사실 이 글을 쓰기 위해 책이나 인터넷에서 많이 올려놓은 정의들을 보았었는데 그 중 c 언어를 통하여 간단히 API와 ABI가 일을 하는 범위 개념 등을 명확하게 알려주는 예제가 있어서 가져와보았다.
원글 - Linux shared library minimal runnable API vs ABI example
명령어 집합 (ISA)
소프트웨어와 하드웨어 사이의 명령어들을 정의하면서 현재 시스템 상태의 변화를 표시해주는 인터페이스
위의 그림에서 보다싶이 하드웨어 자세히 말하면 아키텍쳐 등과 OS 간의 인터페이스로 CPU 등의 상태를 가져오고 기능을 수행할 수 있는 기계어로 된 명령어를 말한다.
추후에 추상화와 함께 ADT개념을 통한 ISA를 자세히 포스팅 하겠다.
'CS > Operating System' 카테고리의 다른 글
운영체제 구조 :: 기술 구조 (2) | 2022.08.02 |
---|---|
운영체제 구조 :: ABI란? 안정적인 ABI (0) | 2022.07.30 |
운영체제 구조 :: 사용자와의 인터페이스 (0) | 2022.07.27 |
운영체제 구조 :: 서비스 (0) | 2022.07.25 |
들어가기에 앞서, 포스팅 로드맵 (0) | 2022.07.25 |