크래프톤 정글 6DAY os의 추상화

참조 레퍼런스

• o/s와 추상화
  o/s에서 추상화란?
  
• 추상화와 가상화
  가상화? 메모리 주소?

os의 추상화

말이 어려워서일까? 아니면 우리가 아직은 근원적인 시스템 프로그래밍 경험이 없어서인가 이 단어가 너무 와닿지 않아서 니나농님의 Q/A시간에 추상화에 대한 질문을 드렸다.
역시 하나에 킹 둘에 임베디드 줄여서 킹베디드 답게 아 그정도는 제가 대답해드릴게요, 대신 이나님이 꼭 교차점검 하고 자료들을 더 찾으세요라고 말씀해주셨다.

추상화는 real이 아니다.

이게 뭔 소리냐면, 예를 들어 크래프톤 정글이 에꼴 과정의 일부를 추상화하여 가져왔다고 해보자.
그러면 크래프톤 정글==에꼴이 성립 가능할까? 아니다…
이것은 o/s에서도 똑같이 성립하며, kotlin을 배워본 사람이라면 추상 클래스와 연관지어 생각해보거나 api에는 함수의 추상화 기능이 있다고 접근하면 좀 더 쉽게 다가올 것이다.

그래서 그게 뭐

• 컴퓨터의 계층을 나누어보자
  [1단계]: H/W
  [2단계]:펌웨어
  [3단계]: o/s
  [4단계]: s/w

아주 다행스럽게도, 통상적인 개발자들은 1단계 개발자라면 1-2단계에 대한 학습을 하고 4단계 개발자라면 3-4단계에 대한 학습을 진행한다.
그 이유는 분량이 굉장히 많아서도 있지만, 대부분의 경우 저 계층의 한 단계 위 아래로 영향을 줄 수는 있어도 그 이상의 영향을 주기 위해서는 사이에 무언가가 있어야하기 때문이다.
만약 그렇지 않았다면 우리는 정글에서 회로도 단계까지 공부를 해야했을 것이다..

본론

o/s는 오퍼레이팅 시스템의 약자로 무엇을 제어하고 싶어하냐면 바로 1단계에 있는 h/w를 컨트롤 하고 싶어한다.
그러나 그것은 불가능하기 때문에 o/s는 커널이라는 추상화의 핵심 기능을 사용하여 h/w와의 내통을 시도한다.
참고로 펌웨어는 o/s로 부터 독립적인 계층이기 때문에 따로 언급하지는 않는 것이다. 그리고 이건 약간 스포일러지만, o/s와 s/w는 드라이버라는 특별한 응용프로그램을 통하여 소통을 한다.
아직 나도 커널에 대해서는 제대로 공부하지 못했지만, 간단하게 설명하자면 하드웨어과 O/S계층 사이에서 인터페이스의 역할을 해준다.

그건 알겠는데요

자 위에 본론이 왜 추상화와 관계가 되냐면 O/S는 하드웨어를 컨트롤하고자 하지만 원칙적으로는 저 위에 나와있는 계층표에서 두 단계나 넘어야 H/W가 위치해있기 때문이다.
O/S는 즉 커널을 통해 H/W와 연결을 할 뿐 아니라, 하드웨어를 추상화 하고 소프트 웨어를 제공하여준다.
또한 펌웨어 계층을 자꾸 설명에서 빼먹고 하는 이유는, 펌웨어는 독립적으로 움직이는 특성이 있어서 그렇다…사실 나도 얘는 잘 모른다.

디스크 컨트롤러

여기까지 내 설명을 듣고나면 아니 이보세요 하지만 디스크 컨트롤러는 분명 버스와 직접 소통을 하는 것 같은데요?라는 생각을 할 수 있다.
이 부분에 대해 설명하기 위해서는 아주 잠깐 동안 메인보드의 구성 및 HDD/SSD의 차이를 소개하는 시간을 가져야만 한다.

메인보드의 구성

정말정말 간략하게 요약하자면 메인보드는 칩셋(IC집합)과 소켓으로 나누어서 설명할 수 있는데, 소켓은 직접적으로 CPU와 내통하도록 하고 싶은 부품들을 넣고 칩셋에는 무언가를 통해 CPU에 접근하도록 할 부품들을 넣는다.
그래서 버스와 칩셋은 하드웨어적 관점이냐 소프트웨어적 관점이냐에 따른 용어차이일뿐 근원적인 역할과 한계는 비슷하다.

근원적 한계점

그것이 뭐냐면 버스와 칩셋은 모두 한번에 전송할 수 있는 양의 한계가 있다는 것이다.
내가 전에 썼던 TIL에서 언급한 것처럼 캐시가 탄생한 것은 병목현상을 해결 하기 위해서이다.
디스크 컨트롤러 역시 약간은 비슷한데, 하드디스크는 느리기 때문에 일종의 쪼개기 방식을 통하여 소통을 진행한다.
그리고 버스나 칩셋 역시 하드웨어적인 이유에서든 소프트웨어적인 문제에서든 용량의 제한이 생긴다.

계층을 뛰어넘을 수는 없다

자 여기까지만 읽었을 때 이제 디스크 컨트롤러가 무엇을 할지는 짐작이 되지만, 왜 이것이 하드웨어 계층에 위치하는지는 이해가 안갈 수 있다.
정상이다, 나도 이것 때문에 임베디드 지인에게 또 연락을 했고 결국엔 전화를 통해 문제를 해결했으니 말이다.
디스크 컨트롤러는 하드디스크를 연결하는 SATA 인터페이스에 연결되어있고, 펌웨어 계층에는 우리가 구동한 O/S를 넣음으로써 하드디스크와 램은 소통하게 된다.

디스크 컨트롤러에는 펌웨어가 있나요

컨트롤러 나름이다.
복잡한 컨트롤러라면 당연 하드 계층과 O/S계층에 위치하는 버스를 연결시켜주기 위해 펌웨어 계층이 있을 것이고, 간단하게 해결 가능한 부분이라면 그렇게 짜지 않을 수도 있다.
펌웨어가 들어가는 컨트롤러의 경우 O/S가 커널을 통한 추상화 과정을 거쳐 디스크 컨트롤러에게 들어갈 것이고 그렇지 않을 경우 컨트롤러가 하드웨어에 의해 컨트롤이 될 것이다. 당연 펌웨어가 들어가는 쪽이 좀 더 오류 제어를 제어하거나 복구를 하는 기능 등을 지원해줄 가능성이 높다.

커널

사실 무책임한 말이지만, 나도 이부분에 대해서는 아직 딥하게 이해를 하지 못했다.
그러나 내가 이해한 바로는 디스크 컨트롤러가 펌웨어를 탑재하지 않은 경우 O/S는 디스크 컨트롤러에게 접근하기 위해 하드웨어 레지스터에게 업무를 내린다.
참고로 레지스터의 경우 일종의 우편함과 같은 역할이어서 하드웨어와 O/S를 잇는 역할이 가능하며, O/S는 디스크에 대한 접근을 레지스터를 통해 받은 뒤 디스크 컨트롤러에게 명령을 내려 데이터를 쓰거나 삭제하도록 요청하는 것이다.
바로 이때 등장하는 것이 위에서 말한 커널로, 하드웨어와의 연결을 관장한다.