하처's Story

감사합니다. 먼저 세계 최고의 명문으로 꼽히는 이 곳에서 여러분들의 졸업식에 참석하게 된 것을 영광으로 생각합니다. 사실 저는 대학을 졸업하지 못했습니다. 태어나서 대학교 졸업식을 이렇게 가까이서 보는 것은 처음이네요. 오늘 저는 여러분께 제 인생의 세 가지 이야기를 해볼까 합니다. 그게 전부입니다. 그저 세 가지 이야기일 뿐입니다.

먼저 인생의 점들을 잇는 것(connecting the dots)에 대해서입니다.

전 리드칼리지에 입학한지 6개월 만에 자퇴했습니다. 그래도 일년 반 정도는 도강을 하다가 정말로 그만뒀습니다. 왜 자퇴했을까요?

이야기는 제가 태어나기 전으로 거슬러 올라갑니다. 제 생모는 대학원생인 젊은 미혼모였습니다. 그래서 저를 입양보내기로 결심했던 거지요. 그녀는 제 미래를 위해 대학을 나온 양부모를 원했습니다. 그래서 저는 태어나자마자 변호사 가정에 입양되기로 되었죠. 하지만 제가 태어난 순간에 변호사 부부는 마지막 순간에 여자 아이를 입양하기로 마음을 바꿨습니다. 대기자 명단에 있던 제 양부모들은 한밤중에 이런 전화를 받게 됩니다. "예정에 없던 사내아이가 태어났는데 입양하시겠습니까?" 양부모님은 대답했습니다. "물론이죠."

그런데 양어머니는 대졸도 아니고 양아버지는 고등학교도 안 나와서 친어머니는 입양동의서 쓰기를 거부했습니다. 몇 달 후 양부모님이 저를 대학까지 가르치겠다고 약속한 후에야 친어머니는 입양에 동의했습니다. 이것이 제 인생의 시작이었습니다.

17년 후 저는 대학에 입학했습니다. 그러나 저는 순진하게도 바로 이 곳 스탠퍼드대의 학비와 맞먹는 값비싼 학교를 선택했습니다. 평범한 노동자였던 부모님이 힘들게 모아뒀던 돈이 모두 제 학비로 들어갔습니다. 6개월 후 대학생활은 그만한 가치가 없어보였습니다. 내가 무엇을 하고 싶은지 또 대학교육이 그것에 얼마나 도움이 될 것인가 알 수 없었습니다. 양부모님들이 평생토록 모은 재산을 쏟아붓고 있었습니다. 그래서 모든 것이 잘 될 거라 믿고 자퇴를 결심했습니다. 당시에는 두려웠지만 뒤 돌아 보았을 때 제 인생 최고의 결정 중 하나였던 것 같습니다. 자퇴 후엔 재미없던 필수과목들을 듣는 것은 그만두고 보다 더 흥미 있어 보이는 강의를 들을 수 있었습니다.

그렇다고 꼭 낭만적인 것만은 아니었습니다. 기숙사에 머물 수 없었기 때문에 친구 집 마룻바닥에 자기도 했고 5센트짜리 콜라병을 팔아 끼니를 때우기도 했습니다. 일요일이면 단 한번이라도 제대로 된 음식을 먹기 위해 7마일을 걸어 하레 크리슈나 사원의 예배에 참석하기도 했습니다. 정말 맛있었습니다. 순전히 호기심과 직감만을 믿고 저지른 일들이 훗날 정말 값진 경험이 됐습니다.

예를 하나 들어 드리죠. 당시 리드 칼리지는 미국 최고의 서체 교육을 제공했던 것 같습니다. 학교 곳곳에 붙어있는 포스터와 서랍에 붙어있는 상표들…. 손으로 아름답게 그린 서체 예술이었습니다. 정규과목을 들을 필요가 없으므로 서체 수업을 들었습니다. 그 때 저는 세리프와 산세리프체를, 다른 글씨의 조합 간의 그 여백의 다양함을 무엇이 위대한 글자체의 요소인지에 대해 배웠습니다. 그것은 '과학적'인 방식으로는 도저히 표현해낼 수 없는 아름답고, 유서 깊고, 예술적으로 미묘한 것이어서 전 매료되고 말았습니다. 이 중 어느 하나라도 제 인생에 실질적 도움이 될 것 같지는 않았습니다. 그러나 10년 후 우리가 첫 번째 매킨토시를 구상할 때 그것들은 고스란히 빛을 발했습니다. 우리가 설계한 매킨토시에 그 기능을 모두 집어넣었으니까요. 그것은 아름다운 서체를 가진 최초의 컴퓨터였습니다.

만약 제가 그 서체 수업을 듣지 않았다면 매킨토시의 복수서체  기능이나 자동 자간 맞춤 기능은 없었을 것이고 맥을 따라한 윈도우도 그런 기능이 없었을 것이고 결국 개인용 컴퓨터에는 이런 기능이 탑재될 수 없었을 겁니다. 만약 학교를 자퇴하지 않았다면 서체 수업을 듣지 못했을 것이고 PC에는 오늘날처럼 뛰어난 글씨체가 없었을 것입니다.

물론 제가 대학에 있을 때 그 순간들이 내 인생의 전환점이라는 것을 알아챌 수 없었습니다. 그러나 10년이 지난 지금에서야 모든 것이 분명하게 보입니다. 달리 말하자면, 지금 여러분은 미래를 알 수 없습니다. 다만 현재와 과거의 사건들만을 연관시켜 볼 수 있을 뿐이죠. 그러므로 여러분들은 현재가 미래와 어떻게든 연결된다는 걸 알아야 합니다. 배짱, 운명, 인생, 카르마(업) 등 그 무엇이든 믿음을 가져야만 합니다. 왜냐하면 현재가 미래로 연결된다는 믿음이 여러분의 가슴을 따라 살아갈 자신감을 줄 것이기 때문입니다. 아무리 험한 길이라 하더라도 말입니다. 그리고 그것이 인생의 모든 차이를 빚어냅니다.

두 번 째 이야기는 사랑과 상실에 관한 것입니다. 저는 운 좋게도 인생에서 정말 하고 싶은 일을 일찍 발견했습니다. 워즈(스티브 워즈니악)와 제가 차고에서 애플사를 세운 것은 제가 20세 때 일입니다. 우리는 열심히 일해서 차고에서 2명으로 시작한 애플은 10년 후에 4000명의 종업원을 거느린 2백억 달러짜리 기업이 되었습니다. 우리는 최고의 작품, 매킨토시를 출시했고 전 30세가 되었습니다. 그리고 곧 저는 해고당했습니다. 어떻게 자기 회사에서 해고당할 수 있냐고요?

당시 애플이 점점 성장하면서 저는 저와 함께 회사를 경영할 유능한 경영자를 데려와야겠다고 생각했습니다. 처음 1년 정도는 그런대로 잘 돌아갔습니다. 그런데 언젠가부터 우리의 비전은 서로 어긋나기 시작했고 결국 우리 둘의 사이도 어긋나기 시작했습니다. 이 때 우리 회사의 경영진들은 존 스컬리의 편을 들었고 저는 30살에 쫓겨나야만 했습니다. 그것도 아주 공공연하게 말이죠.

저는 인생의 초점을 잃어버렸고 참담한 심정이었습니다. 전 정말 말 그대로, 몇 개월 동안 아무 것도 할 수가 없었습니다. 선배 벤처 세대의 명예를 실추시킨 것 같았습니다. 제게 넘겨진 배턴을 놓쳐버린 것 같았습니다. 데이비드 패커드(HP의 공동창업자)와 밥 노이스(인텔 공동창업자)를 만나 이렇게까지 실패한 것에 대해 사과하고자 했습니다. 저는 실패의 본보기였고 실리콘 밸리에서 도망치고 싶었습니다.

그러나 제 맘속에는 뭔가가 천천히 다시 일어나기 시작했습니다. 전 여전히 제가 했던 일을 사랑했습니다. 애플에서 겪었던 일들조차도 그런 마음들을 꺾지 못했습니다. 전 해고당했지만 여전히 일에 대한 사랑은 식지 않았습니다. 그래서 전 다시 시작하기로 결심했습니다. 당시에는 몰랐지만 애플에서 해고당한 것은 제 인생 최고의 사건이었습니다. 성공이란 중압감 대신 찾아온 초심자의 가벼움, 불확실함. 내 인생의 최고의 창의력을 발휘하는 시기로 갈 수 있게 됐습니다. 이후 5년 동안 저는 'NeXT'와 'Pixar'를 세우고 지금은 아내가 되어준 그녀와 사랑에 빠졌습니다.

Pixar는 세계 최초의 3D 애니메이션 토이스토리를 시작으로 지금은 세계에서 가장 성공한 애니메이션 제작사가 되었습니다. 세기의 사건으로 평가되는 애플의 NeXT 인수와 저의 애플로 복귀 후 NeXT 시절 개발했던 기술들은 현재 애플의 르네상스의 중추적인 역할을 하고 있습니다. 또한 로렌과 저는 행복한 가정을 꾸리고 있습니다. 애플에서 해고당하지 않았다면 이 많은 일들이 일어나지 않았을 것입니다. 입에 쓴 약이었지만 제게는 필요했던 것 같습니다. 때로는 인생이 배신하더라도 결코 믿음을 잃지 마십시오. 저를 계속 움직이게 했던 힘은 제 일을 사랑하는 것뿐이었습니다.

여러분이 사랑하는 일을 찾아야 합니다. 여러분의 연인이 여러분에게 의미하는 것처럼 일도 마찬가지입니다. 일은 여러분의 삶의 많은 부분을 채울 것이고 여러분이 위대하다고 믿는 그 일을 하는 것만이 진정한 만족을 줄 것입니다. 위업을 달성하는 것은 당신의 일을 사랑하는 것 입니다. 그 일을 아직 찾지 못했다면 계속 찾으세요. 현실에 안주하지 마십시오. 전심을 다해서 찾아내면 그 때는 알게 될 것입니다. 모든 위대한 관계들이 그러한 것처럼 시간이 갈수록 더 나아질 것입니다. 그러므로 계속 추구하십시오. 안주하지 마십시오.

세 번 째는 죽음에 관한 것입니다. 17살 때 이런 경구를 읽은 적이 있습니다. "매일 인생의 마지막 날처럼 산다면 언젠가는 위인이 되어있을 것이다." 이 글에 감명 받은 저는 그 이후로 지난 33년 간 매일 아침 거울을 보면서 제 자신에게 묻곤 했습니다. '오늘이 내 인생의 마지막 날이라면 지금 하려고 하는 일을 할 것인가?" 며칠 연속 'No'라는 답을 얻을 때마다 나는 변화가 필요하다는 걸 알게 됩니다. '곧 죽는다'는 생각은 인생의 결단을 내릴 때마다 가장 중요한 도구였습니다. 모든 외부의 기대. 자부심, 수치스러움과 실패의 두려움은 '죽음' 앞에선 모두 떨어져나가고 오직 진실로 중요한 것들만이 남기 때문입니다. 죽음을 생각하는 것은 무엇을 잃을지도 모른다는 두려움에서 벗어나는 최고의 길입니다. 여러분은 죽을 몸입니다. 그러므로 가슴을 따라 살아야 합니다.

저는 1년 전쯤 암 진단을 받았습니다. 아침 7시 반에 검사를 받았는데 췌장에 악성종양이 보였습니다. 그때까진 췌장이 뭔지도 몰랐죠. 의사들은 거의 치료할 수 없는 종류의 암이라고 했습니다. 또 길어야 3개월에서 6개월 밖에 살 수 없다고 했습니다. 주치의는 집으로 돌아가 신변정리를 하라고 했습니다. 죽음을 준비하라는 뜻이었죠. 그것은 내 아이들에게 10년 동안 해줄 것을 단 몇 달 안에 다 해내야 된다는 말이었고 가족들이 임종할 때 쉬워지도록 매사를 정리하란 말이었고 작별인사를 준비하라는 말이었습니다. 그렇게 시한부 인생을 살고 있었습니다. 어느 날 저녁 조직검사를 받았는데 위장을 지나 장까지 내시경을 넣어 췌장에서 암세포를 채취하는 조직검사였습니다. 저는 마취상태였는데 후에 아내가 말해주길 의사들이 현미경으로 세포를 분석하면서 갑자기 울먹거리기 시작했답니다. 수술로 치료가 가능한 희귀한 종류의 췌장암이었기 때문입니다. 저는 수술을 받았고 감사하게도 지금은 완치되었습니다. 그 때만큼 제가 죽음에 가까이 가 본 적은 없는 것 같습니다. 또한 앞으로도 수 십 년간은 그렇게 가까이 가지 않길 바랍니다. 이런 경험을 해보니 죽음이 때론 유용하단 것을 머리로만 알고 있을 때보다 더 자신 있게 말할 수 있습니다.

아무도 죽길 원하지 않습니다. 천국에 가고 싶다는 사람들조차도 죽어서까지 가고 싶어 하진 않죠. 그리고 여전히 죽음은 우리 모두의 숙명입니다. 아무도 피할 수 없죠. 그리고 그래야만 합니다. 왜냐하면 삶이 만든 최고의 발명이 '죽음'이니까요. 죽음은 삶을 대신하여 변화를 만듭니다. 죽음은 구세대를 대신하도록 신세대에게 길을 터줍니다. 지금 이 순간 여러분이 곧 신세대입니다. 그러나 머지않아서 여러분도 구세대가 되어 사라져 갈 것입니다. 너무 극적으로 들렸다면 죄송하지만 엄연한 사실입니다. 여러분의 시간은 한정되어 있습니다. 따라서 다른 사람의 삶을 사느라 시간을 낭비하지 마십시오. 타인의 생각의 결과물에 불과한 도그마에 빠지지 마십시오. 타인의 견해가 여러분 내면의 목소리를 삼키지 못하게 하세요. 또 가장 중요한 것은 가슴과 영감을 따르는 용기를 내는 것입니다. 이미 여러분의 가슴과 영감은 여러분이 되고자 하는 바를 알고 있습니다. 그 외의 모든 것은 부차적인 것이죠.

제가 어렸을 때 '지구백과'라고 하는 놀라운 책이 있었는데 저희 세대에게는 바이블과 같은 것이었습니다. 여기서 그리 멀지 않은 먼로 파크에 사는 스튜어트 브랜드란 사람이 쓴 책인데 시적 감각으로 살아있는 책이었지요. PC나 전자출판이 존재하기 전인 1960년대 후반이었기 때문에 타자기, 가위, 폴라로이드로 제작된 책이었습니다.

Google이 등장하기 35년 전 책으로 된 Google같은 거였죠. 그 책은 위대한 의지와 아주 간단한 도구만으로 만들어진 역작이었습니다. 스튜어트와 친구들은 몇 번의 개정판을 내놓았고 수명이 다할 때쯤엔 최종판을 내놓았습니다. 그 때가 70년대 중반, 제가 여러분 나이 때였죠. 최종판 뒤쪽 표지에는 이른 아침 시골길 사진이 있었는데 겁 없는 사람이나 히치하이킹 할 수 있는 풍경입니다. 그 사진 밑에는 이런 말이 있었습니다.

'계속 갈망하라 여전히 우직하게'(Stay Hungry Stay Foolish) 그것이 그들의 마지막 작별 인사였습니다. '계속 갈망하라 여전히 우직하게' 제 자신에게도 항상 그러하기를 바랐습니다. 그리고 지금, 새로운 시작을 위해 졸업을 하는 여러분에게 동일한 바람을 가집니다.
"Stay Hungry Stay Foolish!"
대단히 감사합니다.

 

 

디바이스 제어를 위한 아키텍처 비교

윈도와 리눅스를 비교해 보면 디바이스 제어 방식이 다르다.

윈도 디바이스 제어 아키텍처

윈도에서, I/O 하위 시스템은 사용자 응용이 디바이스 드라이버로 접속하도록 디바이스 드라이버를 지원하는 기반 구조를 정의한다. 디바이스 드라이버는 특정 디바이스 연결을 지원하는 외부 통로인 I/O 인터페이스를 제공한다(그림 1 참조).

그림 1. 윈도 디바이스 제어 아키텍처

디바이스 제어 과정에서, I/O 연산은 IRP(I/O Request Packet)로 캡슐화되어 있다. I/O 관리자는 IRP를 생성해 스택 상위로 보낸다. 그러면 디바이스 드라이버가 I/O 요청을 위한 매개변수가 담긴 IRP를 가리키는 스택 위치를 얻는다. IRP 요구사항에 따르면(create, read, write, devioctl, cleanup, close)) 각 드라이버는 하드웨어 인터페이스를 통해 작업을 수행한다.

리눅스 디바이스 제어 아키텍처

리눅스에서 디바이스 제어 아키텍처는 조금 다르다. 주요 차이점은 일반 파일, 디렉터리, 디바이스, 소켓이 모두 파일이라는 사실이다. 리눅스에서는 모든 것이 파일이다. 디바이스 접근을 위해, 리눅스 커널은 파일 시스템을 통해 디바이스 연산 호출을 디바이스 드라이버로 사상한다. 리눅스에는 I/O 관리자가 없다. 모든 I/O 요청은 처음부터 파일 시스템으로 간다(그림 2 참조).

그림 2. 리눅스 디바이스 제어 아키텍처

 

 

디바이스 파일 이름과 경로 이름 비교

개발 관점에서 바라보면, 디바이스 핸들을 얻는 과정은 디바이스 제어를 위한 선행 조건이다. 하지만 디바이스 제어 아키텍처가 다르므로, 디바이스 핸들을 얻는 방법도 윈도를 사용하느냐 리눅스를 사용하느냐에 따라 이야기가 완전히 다르게 전개된다.

일반적으로 말하자면, 디바이스 핸들은 특정 디바이스 드라이버 이름이 결정한다.

윈도에서는 디바이스 드라이버 파일 이름은 일반 파일 형식과 다르다. 이를 일반적으로 디바이스 경로 이름이라고 하며, \.DeviceName과 같은 고정 형식을 따른다. C/C++ 프로그래밍에서, 이 문자열은 \\.\DeviceName과 같이 표현해야 한다. 코드에서는 \\\\.\\DeviceName과 같이 사용한다. DeviceName은 대응하는 디바이스 드라이버 프로그램에서 정의한 디바이스 이름과 똑같아야 한다.

몇몇 디바이스 이름은 마이크로소프트가 정의했으며, 바뀌지 않는다(표 1 목록 참조).

표 1. 윈도에서 디바이스 이름(x = 0, 1, 2 등)

 

예를 들어, C/C++ 프로그래밍에서 \\\\.\\PhysicalDrive1, \\\\.\\CdRom0, \\\\.\\Tape0 같은 디바이스 경로 이름을 사용한다. 상기 목록에 나와 있지 않은 다른 디바이스에 대한 세부 내역은 이 기사 뒷부분에 나오는 참고자료 절을 참조하자.

리눅스에서 디바이스는 파일로 기술하므로 ./dev 디렉터리에서 디바이스 파일 전부를 찾을 수 있다. 이 디렉터리에 있는 디바이스 드라이버는 다음을 포함한다.

• IDE(Integrated Drive Electronics) 하드 드라이브: /dev/hda, /dev/hdb
• CD-ROM 드라이브: 몇몇은 IDE, 몇몇은 SCSI 디바이스(/dev/scd0와 같이) 에뮬레이션으로 동작하는 CD-RW(CD Read/Write)
• 직렬 포트: /dev/ttyS0(COM1), /dev/ttyS1(COM2)
• 포인팅 디바이스: /dev/input/mice
• 프린터: /dev/lp0

대다수 공통 디바이스 파일은 위에서 설명한 내용에 따라 찾을 수 있다. 다른 디바이스 파일 이름과 세부 디바이스 정보는 dmesg 명령으로 살펴보기 바란다.

 

주요 시스템 호출 비교

디바이스 제어를 위한 주요 시스템 호출은 open, close, ioctl, read/write 같은 연산을 포함한다. 표 2에 정리한 윈도/리눅스 비교 내용을 살펴보자.

표 2. 디바이스 제어 함수 비교

 

이제 가장 일반적인 함수인 create, close, devioctl을 좀 더 깊숙히 파고 들자.

윈도에서 디바이스 여닫기

지금부터는 윈도에서 CreateFile과 CloseHandle을 설명한다. 디바이스를 열기 위해 함수 CreateFile을 사용한다. 이 함수는 객체 접근을 위해 사용하는 핸들을 반환한다. Listing 1을 살펴보자.

Listing 1. 윈도에서 CreateFile 함수

 

               
HANDLE CreateFile (LPCTSTR lpFileName,          // 디바이스 파일 이름
                                                  (디바이스 경로 이름)
   DWORD dwDesiredAccess,                       // 객체에 대한 접근 모드(읽기, 쓰기, 둘 다)
   DWORD dwShareMode,                           // 객체 공유 모드(읽기, 쓰기, 둘 다)
   LPSECURITY_ATTRIBUTES lpSecurityAttributes,  // 자식 프로세스가 반환된 핸들을 상속받을
                                                // 수 있는지를 판단하는 보안 속성
   DWORD dwCreationDisposition,                 // 파일 존재 유무에 따라 적용할 연산
   DWORD dwFlagsAndAttributes,                  // 파일 속성과 플래그
   HANDLE hTemplateFile);                       // 임시 파일에 대한 핸들

매개변수 lpFileName은 직전에 명세한 디바이스 경로 이름이다. 일반적으로 디바이스를 열려면 dwDesiredAccess를 0이나 GENERIC_READ|GENERIC_WRITE로, dwShareMode를 FILE_SHARE_READ|FILE_SHARE_WRITE로, dwCreationDisposition을 OPEN_EXISTING으로, dwFlagsAndAttributes와 hTemplateFile을 0이나 NULL로 설정한다. 반환되는 핸들은 나중에 디바이스 제어 연산에 사용한다.

디바이스를 닫으려면 함수 CloseHandle을 사용한다. 매개변수 hObject는 디바이스를 열 때 반환된 핸들이다. BOOL WINAPI CloseHandle (HANDLE hObject); 형식을 따른다.

리눅스에서 디바이스 여닫기

리눅스에서 open과 close를 설명한다. 직전에 언급했듯이, 디바이스 열기는 일반 파일 열기와 동일하다. Listing 2는 디바이스 핸들을 얻기 위한 open 사용법을 보여준다.

Listing 2. 리눅스에서 open 함수

 

               
int open (const char *pathname,
       int flags,
       mode_t mode);

open 호출이 성공했을 때 반환되는 파일 기술자는 프로세스에서 현재 열리지 않은 가장 낮은 파일 기술자 번호가 될 것이다. 호출에 실패하면, -1을 반환한다. 파일 기술자는 디바이스 핸들로 쓰인다.

매개변수 플래그는 O_RDONLY, O_WRONLY, O_RDWR 중 하나를 포함해야 한다. 나머지 플래그는 옵션이다. 인수 mode는 새 파일을 생성할 경우에 접근 권한을 명세한다.

리눅스에서 함수 close는 파일과 마찬가지로 디바이스를 닫는다. int close(int fd); 형식을 따른다.

윈도에서 DeviceIoControl

윈도에서 DeviceIoControl, 리눅스에서 ioctl은 디바이스 제어를 위해 가장 흔히 사용되는 함수이며 디바이스 접근, 정보 인출, 명령 전송, 자료 교환 같은 작업을 수행한다. Listing 3은 DeviceIoControl을 보여준다.

Listing 3. 윈도에서 DeviceIoControl 함수

 

               
BOOL DeviceIoControl (HANDLE hDevice,
      DWORD dwIoControlCode,
      LPVOID lpInBuffer,
      DWORD nInBufferSize,
      LPVOID lpOutBuffer,
      DWORD nOutBufferSize,
      LPDWORD lpBytesReturned,
      LPOVERLAPPED lpOverlapped);

이 시스템 호출은 제어 코드와 기타 자료를 지정된 디바이스로 보낸다. 대응하는 디바이스 드라이버는 제어 코드인 dwIoControlCode가 지시하는 방식대로 동작한다. 예를 들어, IOCTL_DISK_GET_DRIVE_GEOMETRY를 사용해 물리 드라이버에서 구조 매개변수를 얻을 수 있다(매체 유형, 실린더 개수, 각 실린더에 존재하는 트랙 개수, 각 트랙에 존재하는 섹터 개수 등). 제어 코드 정의, 헤더 파일, 기타 세부 정보는 MSDN 웹 사이트에서 얻을 수 있다(참고자료 절에서 링크를 살펴보자).

입/출력 버퍼가 필요한지 구조체와 크기가 무엇인지는 실제 관련 ioctl 과정과 관련이 있는 디바이스와 연산에 따라 달라진다. 이런 사항은 호출 시에 명세한 dwIoControlCode가 결정한다.

중첩 연산을 위한 포인터를 NULL로 설정하면, DeviceIoControl은 차단 방식(동기식)으로 동작한다. 그렇지 않으면 비동기식으로 동작할 것이다.

리눅스에서 ioctl

리눅스에서는 특정 디바이스에 제어 정보를 전달하는 데 ioctl을 사용한다. int ioctl(int fildes, int request, /* arg */ ...); 형식을 따른다. 첫 번째 매개변수인 fildes는 open() 함수가 반환한 열린 파일 기술자이며 특정 디바이스를 가리킨다.

대응하는 DeviceIOControl 시스템 호출과는 달리, ioctl 입력 매개변수 목록은 고정되어 있지 않다. 매개변수 목록은 ioctl에서 매개변수 request가 지정한 내용과 윈도 DeviceIOControl에서 dwIoControlCode와 같이 ioctl이 수행하는 요청 유형에 따라 달라진다. 하지만 이식 과정에서 올바른 request 매개변수를 선택할 때 주의해야 한다. DeviceIOControl에서 dwIoControlCode와 ioctl에서 request는 동일한 값이 아니며, dwIoControlCode/request를 위한 명시적인 사상 방법도 없기 때문이다. 일반적으로 헤더 파일에서 정의를 살펴보는 방법으로 매개변수 request 값을 선택한다. 모든 제어 코드 정의 내용은 /usr/include/{asm,linux}/*.h에 실려있다.

매개변수 arg는 필요한 작업을 수행하도록 특정 디바이스가 필요한 세부 명령어 정보를 전송하기 위해 남겨져 있다. arg 자료 유형은 제어 요청에 따라 달라진다. 이 인수를 사용해 세부 명령을 보내고 반환 자료를 받을 수 있다.

 

이식 예제

지금부터 윈도에서 리눅스로 이식하는 과정을 예를 들어 살펴본다. 이 예제는 개인용 컴퓨터에 장착된 주 IDE 하드 드라이브에서 SMART 로그를 읽는 방법을 보여준다.

1단계: 디바이스 유형 파악

이미 설명했듯이 리눅스는 각 디바이스를 파일로 취급한다. 첫 단계는 리눅스에서 디바이스 파일 이름을 찾아내는 작업이다. 이 파일 이름을 사용해야 디바이스 제어에 필요한 디바이스 핸들을 얻을 수 있다.

이 예제에서 대상 디바이스는 IDE 하드 드라이브다. 리눅스에서 IDE 하드 드라이브는 /dev/hda, /dev/hdb로 기술한다. 우리가 이식할 예제에서 하드 디스크 디바이스 경로 이름은 \\\\.\\PhysicalDrive0이다. 리눅스에서 대응하는 디바이스 파일 이름은 /dev/hda다.

2단계: 인클루드 헤더 변경

#include 헤더 파일을 리눅스 형식으로 변경해야 한다(표 3 참조).

표 3. #include 헤더 파일

 

windows.h는 디바이스를 여닫는 함수(CreateFile과 CloseHandle)를 위해 인클루드한다. 여기에 대응하도록 리눅스에서 open()과 close()를 위해 필요한 헤더 파일을 인클루드해야 한다. 헤더 파일로 sys/types.h, sys/stat.h, and fcntl.h가 있다.

윈도에서 devioctl.h는 함수 DeviceIoControl을 정의하며, 이 파일을 sys/ioctl.h로 변경해 함수 ioctl이 동작하도록 만든다.

(DDK에 들어있는 헤더 파일인) ntddscsi.h는 디바이스 제어를 위한 제어 코드 집합을 정의한다. 이 예제는 IDE 하드 드라이브만 다루고 있기에 리눅스 프로그램에서는 linux/hdreg.h를 추가하기만 하면 끝난다.

다른 상황에서는 필요한 제어 코드 정의가 들어있는 모든 헤더 파일을 인클루드해야 한다. 예를 들어, 하드 드라이브가 아니라 CD-ROM에 접근하려면 linux/cdrom.h을 대신 인클루드한다.

3단계. 함수와 매개변수 수정

이제 코드를 상세히 들여다보자. Listing 4는 명령어 세부 사항을 보여준다.

Listing 4. 명령어 세부 사항

 

               
unsigned char cmdBuff[7];
cmdBuff[0] = SMART_READ_LOG;  // SMART "명령"을 명세하기 위해 쓰인다.
cmdBuff[1] = 1;               // IDE 섹터 계수 레지스터
cmdBuff[2] = 1;               // IDE 섹터 번호 레지스터
cmdBuff[3] = SMART_CYL_LOW;   // IDE 실린더 값(LOW)
cmdBuff[4] = SMART_CYL_HI;    // IDE 실린더 값(HI)
cmdBuff[5] = 0xA0 | (((Dev->Id-1) & 1) * 16); // IDE 드라이브/헤더 레지스터
cmdBuff[6] = SMART_CMD;       // 실제 IDE 명령

명령어 정보는 ATA 명령어 명세에서 가져왔다. 리눅스로 코드를 이식하기 위해 변경이 필요하지 않으므로 추가 분석은 여기서 마친다.

Listing 5에 제시한 코드는 윈도에서 주 하드 드라이브를 연다.

Listing 5. 윈도에서 주 하드 드라이브를 열기

 

               
HANDLE devHandle = CreateFile("\\\\.\\PhysicalDrive0",           // 경로 이름
                             GENERIC_WRITE|GENERIC_READ,         // 접근 모드
                             FILE_SHARE_READ|FILE_SHARE_WRITE,   // 공유 모드
                             NULL,OPEN_EXISTING,0,NULL);

리눅스에서 여닫기에는 매개변수 두 개가 필요하다는 사실을 기억하자(파일 경로 이름과 디바이스에 대한 접근 모드). 직전에 살펴본 원본 코드에서 첫 번째는 /dev/hda이며 두 번째는 O_RDONLY|O_NONBLOCK이다. 변경된 코드는 다음과 같다. HANDLE devHandle = open("/dev/hda", O_RDONLY | O_NONBLOCK); 또한 CloseHandle(devHandle);을 close(devHandle);로 바꾼다.

특정 디바이스에 접근해 원하는 정보를 가져오기 위한 ioctl 용법이 핵심이다. Listing 6에 원본 윈도 코드를 제시한다.

Listing 6. 윈도에서 DeviceIoControl 원시 코드

 

               
typedef struct _Buffer{
       UCHAR   req[8];              // 제어 코드 이외 세부 명령 정보
       ULONG   DataBufferSize;      // DataBuffer 크기, 여기서는 512
       UCHAR   DataBuffer[512];     // 자료를 담을 버퍼
} Buffer;

Buffer regBuffer;
memcpy(regBuffer.req, cmdBuff, 7);  // req[7]은 장래 사용을 위해 예약되어 있으며 0이다.
regBuffer.DataBufferSize = 512;
unsigned int size = 512+12;         // regBuffer 크기
                                    // req를 위해 8, DataBufferSize를 위해 4, 자료를 위해 512
DWORD bytesRet = 0;                 // 반환되는 바이트 개수
int retval;                         // 반환값

retval = DeviceIoControl(devHandle,
                         IOCTL_IDE_PASS_THROUGH,  // 제어 코드
                         regBuffer, // 입력 버퍼, 세부 명령 크기를 포함한다.
                         size,
                         regBuffer, // 출력 버퍼, 여기서는 동일한 버퍼를 사용한다.
                         size,
                         &bytesRet, NULL);
if (!retval)
        cout<<"DeviceIoControl failed."<<endl;
else
memcpy(data, retBuffer.DataBuffer, 512);

DeviceIoControl은 ioctl보다 많은 매개변수를 요구한다. 디바이스 핸들은 양쪽 플랫폼에서 첫 번째 매개변수이며, 리눅스에서는 open(), 윈도에서는 CreateFile에서 반환되는 값이다. 하지만 윈도에서 dwIoControlCode와 리눅스에서 request는 다른 방식으로 정의되기에, 직전에 설명했듯이 두 매개변수 사이에 사상 관계를 정의하는 고정 규칙은 없다. IOCTL_IDE_PASS_THROUGH는 헤더 파일 ntddscsi.h에 CTL_CODE (IOCTL_SCSI_BASE, 0x040a, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)로 정의되어 있다. /usr/include/linux/hdreg.h 헤더 파일에서 정의를 찾아서 리눅스용 대응 제어 코드인 HDIO_DRIVE_CMD를 선택한다.

추가적으로 특정 과업을 수행하기 위해 디바이스가 세부 명령어 정보를 요구한다. 이 명령어는 프로세스에서 커널로 전달 자료를 저장하는 버퍼에 넣는다. 또한 이 버퍼로 반환 자료가 넘어온다. 명령어를 보내고 필요한 로그 정보를 얻기 위해 동일한 버퍼를 사용한다. 리눅스에서 자료 버퍼를 지정하는 크기 매개변수는 제거할 수 있다. 이 예제에서는 (윈도처럼) 명령어 8바이트를 모두 사용하는 대신 (리눅스에서는) 명령어 4바이트만 사용한다.

대응하는 리눅스 코드(Listing 7)가 상당히 단순해 보이는 이유는 윈도보다 구조체와 함수 인수가 더 간단하기 때문이다.

Listing 7. 리눅스에서 ioctl 원시 코드

 

               
int retval;
unsigned char req[4+512]; // 세부 제어 정보와 반환 자료를 위해 충분한 공간
req[0]= cmdBuff[6];       // 이 예제에 필요한 요구사항을 고려할 때 4바이트만 사용한다.
req[1]= cmdBuff[2];
req[2]= cmdBuff[0];
req[3]= cmdBuff[1];

retval = ioctl(devHandle, HDIO_DRIVE_CMD, &req);
if(ret)
        cout<<"ioctl failed."<<endl;
else
memcpy(data, &req[4], 512);

4단계. 리눅스 환경에서 테스트하기

헤더 파일, 함수, 매개변수를 수정했다면 프로그램은 리눅스에서 동작할 준비가 끝났다. 이제 리눅스 플랫폼에서 컴파일한 다음에 남아있는 구문 오류를 수정한다. 리눅스 배포판과 컴파일 환경에 따라 몇 가지 추가 수정이 필요할지도 모른다.

 

참고자료

교육

• 윈도-리눅스 로드맵 연재물에서 이비즈니스 아키텍트인 Chris Walden은 기사 아홉 개로 구성된 연재물을 통해 윈도에서 리눅스로 이주하기 위한 운영 기술을 설명한다. 각 기사에서는 로그부터 네트워크, 명령행부터 도움말 시스템, 심지어 원시 코드에서 패키지 컴파일까지 방대한 내용을 다룬다. 리눅스에서 디바이스를 다루는 내용을 설명하는 "Windows-to-Linux roadmap: Part 6. Working with partitions and file systems"(developerWorks, 2003년 11월)에 특히 주목하자.
• Migration station 참고자료는 윈도와 OS/2에서 동작하는 응용을 x86, POWER, System z 기반 리눅스에서 동작하는 응용으로 이식하도록 도와준다.
• 윈도 디바이스 이름에 대한 세부 사항은 MSDN에서 Device File Names를 참조하자.
• 디바이스를 다루기 위한 윈도 함수 세부 동작 방식은 MSDN에서 CreateFile Function을 참조하자.
• "UNIX Application Migration Guide"는 유닉스 응용을 이식하기 위한 지침과 우수 개발법을 포함한다.
• developerWorks 리눅스 영역에서 가장 인기 있는 기사와 튜토리얼을 비롯하여 리눅스 개발자를 위한 다양한 참고자료를 살펴보기 바란다.
• developerWorks에서 리눅스 팁과 리눅스 튜토리얼을 읽어보기 바란다.
• developerWorks 기술 행사와 웹 캐스트를 놓치지 말자.

 

원본 위치 <http://www.ibm.com/developerworks/kr/library/l-devctrl-migration/index.html>