xv6-book (Ch2.1-Abstracting physical resources)

물리적 리소스 추상화

운영 체제를 만나게 되면 가장 먼저 떠오르는 질문 중 하나는 "왜 운영 체제가 필요한가?"에 대해 생각할 수 있습니다. 이유 중 하나는 시스템 호출을 라이브러리로 구현하여 응용 프로그램이 링크될 수 있다는 점이 있습니다. 이 계획에서 각 응용 프로그램은 필요에 맞게 조정된 자체 라이브러리를 가질 수도 있습니다. 응용 프로그램은 하드웨어 리소스와 직접 상호 작용하고 해당 리소스를 응용 프로그램에 가장 적합한 방식으로 사용할 수 있습니다. 일부 임베디드 장치나 실시간 시스템용 운영 체제는 이러한 방식으로 구성됩니다.

 

이 라이브러리 접근 방식의 단점은 여러 애플리케이션이 실행 중인 경우, 애플리케이션들이 잘 행동해야 한다는 점입니다. 예를 들어, 각 애플리케이션은 주기적으로 CPU를 양보하여 다른 애플리케이션이 실행될 수 있어야 합니다. 모든 애플리케이션이 서로를 신뢰하고 버그가 없다면 이러한 협력적인 시간 공유 방식은 괜찮을 수 있습니다. 그러나 일반적으로 애플리케이션들이 서로를 신뢰하지 않고 버그가 있기 때문에 협력적인 방식이 제공하는 것보다 더 강력한 격리가 필요한 경우가 많습니다.

 

강력한 격리를 달성하기 위해서는 애플리케이션이 민감한 하드웨어 리소스에 직접 접근하는 것을 금지하고, 대신 리소스를 서비스로 추상화하는 것이 도움이 됩니다. 예를 들어, Unix 애플리케이션은 파일 시스템의 open, read, write 및 close 시스템 호출을 통해서만 저장소와 상호 작용하며, 직접 디스크를 읽고 쓰는 대신에 이러한 추상화된 인터페이스를 사용합니다. 이는 응용 프로그램에 경로 이름의 편리성을 제공하고, 인터페이스를 구현하는 운영 체제가 디스크를 관리할 수 있게 합니다. 격리가 고려되지 않더라도, 의도적으로 상호 작용하는 프로그램들(또는 서로의 길을 방해하지 않으려는 프로그램들)은 직접 디스크를 사용하는 대신 파일 시스템을 더 편리한 추상화로 생각할 것입니다.

 

비슷하게, Unix는 하드웨어 CPU를 프로세스들 사이에 투명하게 전환하여 시간 공유에 대해 인식할 필요가 없도록 레지스터 상태를 저장하고 복원합니다. 이 투명성은 어떤 애플리케이션이 무한 루프에 빠져 있더라도 운영 체제가 CPU를 공유할 수 있도록 합니다. 또 다른 예로, Unix 프로세스들은 메모리 이미지를 구성하기 위해 exec를 사용하며, 물리적 메모리와 직접 상호 작용하는 대신에 사용합니다. 이렇게 함으로써 운영 체제가 프로세스를 메모리에 어디에 배치할지 결정할 수 있습니다. 메모리가 부족한 경우, 운영 체제는 프로세스의 데이터 일부를 디스크에 저장할 수도 있습니다. Exec는 또한 사용자에게 실행 가능한 프로그램 이미지를 저장하기 위한 파일 시스템의 편의성을 제공합니다.

 

 

xv6: a simple, Unix-like teaching operating system (mit.edu) Figure 1.2

 

 

유닉스 프로세스 간의 많은 상호 작용 형태는 파일 디스크립터를 통해 발생합니다. 파일 디스크립터는 많은 세부 사항들을 추상화할 뿐만 아니라 상호 작용을 간소화하는 방식으로 정의되어 있습니다. 예를 들어, 파이프 라인의 한 애플리케이션이 실패하면, 커널은 파이프 라인의 다음 프로세스에 대해 파일의 끝 신호를 생성합니다. 시스템 호출 인터페이스는 프로그래머의 편의성과 강력한 격리의 가능성을 모두 제공하기 위해 주의 깊게 설계되었습니다.

 

 

tailored : 맞춤형

downside : 단점

forbid : 금지하다

sensitive : 민감한

transparently : 투명하게