파라미터 전달과 os 구현

sun202x·2023년 1월 18일
0

운영체제

목록 보기
7/23
post-thumbnail

해당 게시글은 kocw에서 제공하는 금오공과대학교 최태영 교수님의 무료 강의를 공부하고 정리하기 위해서 만들어졌습니다.

System call 파라미터 전달

  • fscanf 함수를 호출한다고 했을 때,
    • 파라미터와 함께 호출 된다.
    • fscanf 내부에서 API인 read 함수를 파라미터와 함께 호출
      • 이 때 파라미터는 fscanf로 넘겨받은 파라미터와 다름
    • read API 함수 내에서는 system.call을 호출한다.
      • system.call에 어떤 서비스(read)인지 전달, 이 값은 상수이다.
    • system.call 내에서는 어떤 서비스(read) 였는지 EAX 레지스터에 저장하고 interrupt 128번을 호출 한다.
    • 128에 해당되는 인터럽트 핸들러 루틴에서는 서비스 주소를 가지고 있는 테이블을 참조하고 있다.
    • EAX 레지스터에 저장된 상수 값을 가지고 이 테이블에서 서비스 주소를 찾는다.
    • 찾은 서비스 주소를 가지고 호출하게 되는데, 이 때 파라미터를 전달하는 방법이 있다.
    1. cpu가 사용하는 레지스터에 파라미터를 집어넣는 방식
    • 각 전달받은 파라미터들을 하나의 레지스터에 각각 저장한다.
    • 호출된 서비스에서는 저장된 값들을 레지스터에서 꺼내서 쓰기만 하면 된다.
    • 이 방식의 장점은 레지스터를 활용했기 때문에 속도가 빠르고, 구현하기 쉽다는 점이다.
    • 단점은 하드웨어에 따라 레지스터의 크기가 작은 경우 이 방법을 쓸 수 가 없다.
      • 인텔 컴퓨터 중 8개의 레지스터 밖에 제공되지 않는 컴퓨터가 있음
    1. 특정한 메모리를 할당받는 방식
    • 메모리에 전달받은 파라미터를 저장한다.
    • EBX 레지스터에 이 메모리 주소를 로딩한다.
    • system.call에서 서비스를 호출할 때, EBX 레지스터에 저장된 메모리 위치를 활용하여 파리미터를 가져온다.
      • Load ECX, EBX[0]
      • Load EDX, EBX[1]
      • Load xxx, EBX[2]
    • 이 방식의 장점은 메모리에 여유만 있다면, 얼마든지 많은 파리미터를 전달해 줄 수 있다. 그렇기 때문에 범용성이 높아진다.
    • 단점은 첫 번째 방법에 비해 속도가 떨어지고, 메모리 확보를 위한 시간이 필요하다. 또한 한 메모리에 있는 내용을 다른 메모리에 옮겨주어야 한다.
    • 해당 방식은 리눅스와 솔라리스에서 사용되고 있다.
    1. 보통 함수를 호출할 때, call을 호출하는 방식
    • 일반적인 경우 각 프로세스들은 stack을 가진다.
      • stack에는 return address, 파라미터, local variable을 담아둔다.
    • 이런 것처럼 마찬가지로 system call에도 stack을 두고 필요한 파라미터를 담아둔다.
    • 실제로 system call에서 서비스를 호출 할 때, stack의 내용을 꺼내서 쓴다.
      • pop ECX
      • pop EDX
      • pop xxx
    • 리눅스와 솔라리스에서는 2, 3번 방법을 다 쓰며 파라미터가 적으면 두 번째 방법을, 많으면 세 번째 방법을 쓴다.
    • 해당 방식은 stack에 넣은 순서를 잘 고려해서 써야 한다.

System call 타입

  • 사실 kernel이 해주는 일과 System.call이 해주는 일은 동일하다.
    • 차이는 system.call은 사용자가 요구하는 일이라는 것이고,
    • kernel은 사용자가 요구하지 않아도 처리되는 일이라는 것이다.
      • protection, security 같은 것들
  • System.call은 다음과 같은 역할들을 한다.
    • process 제어
      • 프로세스 생성, 제거
      • 프로세스간 통신
      • 프로세스 실행 중단
      • 등등
    • File 관리
      • 파일 생성, 제거
      • 파일 열기, 닫기
      • 읽기, 쓰기, 위치 변경
      • 등등
    • Device 관리
      • 디바이스를 접근하여 제어하는 것들
      • 디바이스 읽기, 쓰기, 위치 변경
      • 등등
      • 파일과 매우 흡사한데, 이는 리눅스 상에서 디바이스를 파일처럼 다루게 하기 때문이다.
        • open, close, read, write 등
    • Information maintenance(시스템 정보)
      • 현재 시각 등
    • Communications(통신)
    • Protection
  • POSIX Standard를 만들 때, 되도록 적은 API와 System.call을 제공하자는 철학을 바탕으로 만들어서 필요한 system.call만 현재는 제공되고 있다.
    • 윈도우에서도 이러한 system.call과 1대1로 매핑된 것들이 있다.

System programs

  • OS와 하드웨어를 활용하기 위해서 사용자에게 제공되는 프로그램이다.
  • 대표적인 시스템으로,
    • 메모장, 익스플로러, shell
  • 시스템 프로그램을 통해서 사용자는 원하는 일을 수행한다.
    • 파일 관리, 시스템 정보 확인, 컴파일러, shell 실행 등
  • Background Program
    • 시스템 프로그램 중에서 사용자 입력이나 요청을 받지 않고 주어진 일만 하는 프로그램을 Background Program이라고 한다.
    • 네트워크 데이터 처리
    • 디스크 상태 체크
    • 프린트 기능
    • 이런 것들이 하나의 프로세스로서 동작하게 된다.
  • Application Program
    • 이외 프로그램들은 일반적으로 Application Program이라고 한다.
  • User Interface(UI)에 포함되는 시스템 프로그램
    • shell, gui 프로그램 이 두가지는 기본적으로 포함된다.
    • 나머지 시스템 프로그램은 이 UI를 통해 기본적으로 실행된다.
  • 시스템 프로그램은 User Interface를 포함한다.
  • bios는 cmos나 ROM에 들어있다.
    • bios는 부팅 때 짧게 쓰이며,
    • 현재 컴퓨터에 붙어 있는 디바이스들을 체크하고
    • bootstrap 기능을 실행한다.
    • bios는 하드웨어의 작은 부분으로 존재하며, os에 포함되지 않는다.
    • 따라서 시스템 프로그램이 아니다.

운영체제 디자인

  • 대부분은 풀 수 없는 문제들이다.
  • 목적을 정확히 정해야 한다.
  • 어떤 하드웨어에서 쓰일지 명확해야 한다.
  • 시스템에서 하드웨어를 효율적으로 사용할 수 있도록 해야 한다.
  • 이러한 것을 정리해보면 아래 두가지로 나눌 수 있다.
    • Policy: 정책, 무엇을 할 것인가?
    • Mechanism: 정책을 어떻게 동작하게 할 것인가?
  • search 기능에 이 두가지 개념을 도입해보면
    • Policy: search
    • Mechanism: linear search, search tree, hash
    • 위와 같은 방식으로 표현할 수 있다.

운영체제 구현

  • 어떤 프로그래밍 언어를 쓸지 결정
    • 초기에는 어셈블리로 구현
    • 현재는 c, c++
    • Profile을 통해 사용빈도가 높은 부분만 어셈블리로 구현
profile
긍정적으로 살고 싶은 개발자

0개의 댓글