Notice
Recent Posts
Recent Comments
05-18 00:26
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Archives
Today
Total
관리 메뉴

Byeol Lo

2.6 Why Applications are Operating-System Specific 본문

OS/OS Design

2.6 Why Applications are Operating-System Specific

알 수 없는 사용자 2024. 4. 9. 00:54

 기본적으로 한 운영체제에서 컴파일 된 응용 프로그램은 다른 운영 체제에서 실행할 수 없다. 해당 운영 체제의 아키텍처에 맞게 컴파일이 이미 되어 있기 때문에, 실행을 하려면 해당 기계어 들을 다시 다른 운영 체제와 아키텍처에 맞춰주어야 하기 때문이다. 이 문제에서 각 운영체제가 응용 프로그램 사용을 위해 고유한 시스템 호출 세트를 제공하고, 시스템 호출은 운영 체제가 응용 프로그램을 사용하기 위해 제공하는 서비스 세트의 일부다. 시스템 호출이 어떻게든 통일된다고 해도 다른 장벽들이 있어서 우리가 다른 운영체제에서 응용 프로그램을 실행하는 것을 어렵게 만든다. 응용 프로그램을 여러 운영체제에서 실행되게 만드는 방법은 세가지가 있다.

  1. 응용 프로그램은 여러 운영체제에서 사용할 수 있는 인터프리터가 있는 interpreted language(Python, Ruby, ...)로 작성될 수 있는데 인터프리터는 소스 프로그램의 각 줄을 읽고, 네이티브 명령 세트에서 동등한 명령을 실행하고, 네이티브 운영체제를 호출한다. 성능은 네이티브 응용 프로그램에 비해 떨어지고, 인터프리터는 각 운영체제의 기능 중 일부만 제공하여, 관련 응용 프로그램의 기능 세트가 제한될 수 있다.
  2. 응용 프로그램은 실행중인 응용 프로그램을 포함하는 가상 머신을 포함하는 언어로 작성될 수도 있다. 가상 머신 언어의 전체 RTE(런타임 환경)의 일부다. 이 방법의 한 예로 자바가 있는데, 로더, 바이트 코드 검증기자바 응용 프로그램을 자바 가상 머신에 로드하는 다른 구성 요소를 포함하는 RTE를 가지고 있다. 이 RTE는 메인프레임부터 스마트폰에 이르기까지 많은 운영체제에 포팅되고 개발되었으며, 이론적으로 어떤 자바 앱이든지 JRE(자바 런타임 환경)가 있다면 어디서든 RTE 내에서 실행할 수 있다.
  3. 개발자는 컴파일러가 기계 및 운영 체제 특정 언어로 바이너리를 생성하는 표준 언어 또는 API를 사용할 수 있다. 이때 응용 프로그램은 실행 될 각 운영체제에 맞게 포팅되어야 하고, 이 포팅 작업은상당히 긴 시간이 걸리며, 응용 프로그램의 새 버전마다 테스트 및 디버깅이 함께 수행되어야 한다.

 이론적으로 이 접근 방식들은 다양한 운영 체제에서 실행될 수 있는 응용 프로그램을 개발하기 위한 간단한 해결책을 제공하는 것처럼 보일 것이다. 하지만 응용 프로그램의 이동성 부족은 여러 원인에 기인하고 모든 것이 여전히 크로스 플랫폼 응용 프로그램 개발을 어려운 과제로 만든다. 그런 문제들은 다음과 함께 포함하여 다양한 형태의 문제가 발생한다.

  • 각 운영체제는 헤더, 명령어, 변수의 레이아웃을 지시하는 응용프로그램에 대한 바이너리 형식을 가진다.
  • CPU들은 다양한 명령어 집합들과 알맞게 실행할 수 있는 적절한 명령어들을 포함하는 응용 프로그램들을 가진다.
  • 운영체제는 파일 생성, 네트워크 연결 열기와 같은 다양한 활동을 요청할 수 있도록 응용 프로그램에 시스템 호출을 제공한다. 이 호출은 구체적인 피연산자들의 순서, 어떻게 시스템 호출을 호출하는지, 시스템 호출의 번호와 수, 의미, 결과의 반환 등은 운영체제 마다 다르다.

 이러한 아키텍처 차이를 해결하기 위해서 몇 가지 접근법이 있다(완전한 해결책은 아님). 리눅스와 거의 모든 UNIX 시스템은 바이너리 실행 파일에 대해 ELF 형식을 채택하고, ELF 형식은 특정 컴퓨터 아키텍처에 구속되지 않기 때문에 실행 파일이 다른 하드웨어 플랫폼에서 실행될 것이라는 보장을 하지 않는다.

 API는 응용 프로그램 수준에서 특정 함수를 지정한다. 아키텍처 수준에서는 응용프로그램 바이너리 인터페이스(ABI) 가 주어진 운영체제에서 주어진 아키텍처에 대해 바이너리 코드의 다양한 구성요소가 어떻게 인터페이스 할 수 있는지 정의하는데 사용된다. ABI는 주소 폭, 시스템 호출에 매개변수를 전달하는 방법, 런타임 스택의 조직, 시스템 라이브러리의 바이너리 형식, 데이터 유형의 크기 등과 같은 저수준 세부 사항을 지정한다.

 일반적으로, ABI는 주어진 아키텍처에 대해 지정된다. 따라서 ABI는 API가 하는 일을 하드웨어나 아키텍처 차원에서 해주는 것과 같다. 특정 ABI에 따라 컴파일되고 연결된 바이너리 실행 파일이 있다면, 그 ABI를 지원하는 다른 시스템에서 실행될 수 있어야 한다. 그러나 특정 운영 체제가 주어진 아키텍처에서 실행되는 특정 ABI로 정의되기 때문에, ABI는 크로스 플랫폼 호환성을 제공하는 데 거의 도움이 되지 않는다.

 요약하자면, 응용 프로그램이 특정 운영 체제와 특정 CPU 유형에 맞추어 제대로 작성되고 컴파일되었다면, 즉, 해당 시스템의 요구 사항과 호환되도록 만들어졌다면, 실행에 성공할 것이라는 것이다. 반면, 만약 이러한 조건들을 충족시키지 않았다면, 즉, 특정 운영 체제나 CPU 유형을 고려하지 않고 컴파일되었다면, 응용 프로그램은 실행에 실패할 것이다.

'OS > OS Design' 카테고리의 다른 글

2.8 Operating-System Structure  (0) 2024.04.09
2.7 Operating-System Design and Implementation  (0) 2024.04.09
2.5 Linkers and Loaders  (0) 2024.04.08
2.4 System Services  (0) 2024.04.08
2.3 System Calls  (1) 2024.04.08
Comments