WOONY's 인사이트

대망의 마지막 시스템 콜 파트.. 하지만 구현이 전부가 아니다. 구현 100점 하면 뭐하나. 이해 못하면 말짱 꽝이다. 어차피 정답은 검색하면 다 나온다. 내가 해야 할 것은 이게 왜 맞고 틀린지, 뭐가 좋고 안 좋은지, 대체 이 흐름이 어떻게 진행되고 있는 건지를 이해하는 것. 근-본을 이해하지 못하면 백날 구현해봤자 쓸데없다. 면접 가서 "구현 다했습니다!"라고 하면 "와..구현을 다 하셨다니 대단해요!"라고 할 줄 아나. "그래서 뭘 이해했죠? 뭘 배웠죠? 그걸 왜 썼죠? 왜 쓰면 안되죠? 더 나은 방법은 없나요? 예를 들면 이런 상황에서는 그걸 쓸 수 있나요?" 이런 거 물어본다. 구글링하다 보게 된 면접 후기 글에서 이런 말이 있더라. 예를 들어, Deadlock 해결방법에 대한 질문에 프로세스..

시스템 콜 과제 이어서. 한양대 핀토스 pdf에서는 이 챕터를 process hierachy라고 명명하는데, 그냥 system call로 이어서 하겠다. 지난 과제에서는 halt(), create(), remove(), exit()에 대해 정리했다. 여기서 잠시 리마인드해보기. 이 과제를 왜 하고 있지? 지금 우리가 하는 일은 시스템 콜 핸들러를 구현하는 것이다. 왜 이게 필요하지? 유저 프로그램에서 운영체제 혹은 하드웨어에 직접 접근하지 않고 커널에다가 요청(시스템 콜)만 하면 운체가 시스템 콜 핸들러를 이용해 내부적으로 작업하고 결과값만 휘리릭~하고 넘겨주기 위한 것이다. 이 작업으로 유저 프로그램은 복잡한 아랫단까지 내려갈 것 없이 결과만 호로록 받으면 되는 것! 뿐만 아니라 이렇게 작업하면 유저 ..

1. 과제 목표: 시스템 콜 핸들러 및 시스템 콜 구현 Gitbook 설명을 보기 전에, 먼저 시스템 콜의 개념부터 살펴보자. (참고로, user memory access 파트는 시스템 콜의 일부로 check_address()를 구현하는 파트이다. 따라서 시스템 콜 구현에서 함께 설명한다.) 시스템 콜이란? 시스템 콜은, 위 이미지에서 얘기하는 것처럼 운영 체제가 제공하는 서비스에 대한 프로그래밍 인터페이스이다. 유저 프로그램이 함부로 OS에 접근하다가는 보안부터 시작해서 여러 문제를 야기할 수 있다. 또한 이전에 얘기했듯, 유저 프로그램이 하드웨어 단까지 내려가서 작업하는 게 여간 복잡한 게 아니다. 이를 위해서 운영체제를 제공한 것인데 운영체제 내부도 여간 복잡한 게 아니지 않겠나. 따라서 OS의 중..