2010. 7. 20. 17:53 과거 저장소/Device Driver
728x90

예전에 대충 알고 있었던 부분들을 이 책을 통하여 다시금 정리하고 있다.
오늘 읽은 페이지 : 1~107 page

- 유저모드 라이브 디버깅 정리

WinDbg를 이용하여 응용프로그램에 연결하는 방법 3가지
1.
WinDbg에서 응용프로그램 실행하기(Debugger에서 Debugee 실행)
  - File -> Open Executable메뉴를 이용하여 원하는 응용프로그램을 선택한다.
  - 선택 후 열기를 누르면 프로세스 초기화가 끝난 후 main()함수 진입전 한번 멈춘다.
  - 이때 원하는 함수에 BreakPoint를 설정 한 후 g or F5를 눌러 진행하게 된다.

2. 실행중인 응응프로그램에 WinDbg 붙이기(Debugger를 Debugee에 붙이기)
  - 주로 특별한 조건으로 실행된 상태의 응용프로그램을 디버깅해야 할 때나 서비스 프로세스를 디버깅해야 할 때 사용
  - File -> Attach to a Process메뉴를 이용하여 현재 실행중인 프로세스들 중 디버깅을 원하는 프로세스를 선택한다.
  - 다음은 프로세스 초기화 후 멈추게 되는데 여기선 main()함수는 이미 실행되어 지나간 후 라 어떤 부분에서 멈춘지는 알 수 없다.
  ※ WinDbg를 종료하면 실행중이던 응용프로그램도 같이 종료하게 된다. 이것을 막기 위하여 위 Attach 설정창엣 Noninvasive를 선택하면된다. WindowsXP부터는  Noninvasive모드를 사용하지 않아도 qd(Quit and Detach)명령을 이용하여 동일한 기능을 기대할 수 있다.

3. 응용프로그램 실행 중 문제가 발생했을 때 자동으로 WinDbg 실행하기
  - 위 말처럼 응용프로그램의 실행 중에 문제가 발생 시 알아서 자동으로 WinDbg를 실행해준다.
  - 이 기능은 레지스트리에 존재하는 AeDebug키를 이용한다.
    C:\Users\acedon>windbg -I

BreakPoint의 사용
  - bp(BreakPiont)라는 명령어를 사용하여 원하는 곳에 디버깅을 시작할 수 있다.
  - 사용 예) 0:001>bp MyApp!CMyAppDlg::OnBreakPoint
  ※가급적 MyApp처럼 모듈명을 적어주는 것이 명령 실행 시간이 줄어든다.
  - bl(BreakPoint List)라는 명령어는 Breakpoint걸린 목록을 보여준다.
  - 사용 예) 0:001>bl
                    0  e  00401b3e          0001   (0001)   0:**** MyApp!CMyAppDlg::OnBreakPoint
  - 맨 앞 0은 ID로서 0번 브레이크 포인트라는 의미
  - e 는 enable되어 있다는 의미
  - 00401b3e는 breakpoint설정된 주소값
  - 0001은 브레이크 포인트 패스 카운트로서 브레이크 포인터를 1번 만나면 정지해 달라는 의미! 0002였다면 첫 번째 BP가 걸렸을 때는 무시하고 두 번째 브레이크 포인트가 걸렸을 때 정지한다
  - ****은 스레드 지정을 표시함, 스레드 번호 없이 ****가 붙었으면 모든 스레드에 대해서 브레이크 포인트 적용!
  - 나머지 부분은 함수 이름이다.
  - be(Breakponit Enable), bd(Breakpoint Disable)를 이용하여 브레이크 포인트의 사용을 제어 할 수 있다. ex)bd 0  //disable , be 0  //enable
  - bc(Breakpoint Clear)를 이용하여 정의된 브레이크 포인트를 해제한다. ex)bc 0  //0번 브레이크포인트 해제, bc *  //모든 브레이크, bc 3-5, bc 2,7,8
  ** bu명령어는 bp명령어와 동일한 목적으로 사용되나 디버깅을 종료한 후 다시 시작할 때에도 브레이크 포인트가 유지된다는 사실이다.


Call Stack 확인
  - 디버깅 중 브레이크 포인트가 걸렸을 때 대부분 먼저 하는 일은 콜 스택(call stack)확인이다. 어떤 함수들이 어떤 순서로 해당 함수를 호출했는지 확인하는 것이 디버깅의 시작점이 되는 경우가 많기 때문이다. 콜스택을 보는 방법은 두가지가 있다.
  1. 콜 스택 창을 띄워서 보는 방법(File -> View -> Call Stack(ALT+6))
  2. 명령창에서 k명령(Display Stack Backtrace)으로 보는 방법

728x90
posted by acedon
2008. 11. 16. 02:25 과거 저장소/Device Driver
728x90
아~ 황금같은 주말, 비는 오긴 했지만 참으로 유익한 시간을 보내고야 말았습니다.

오늘은 숭실대에서 KOSR세미나가 있었습니다.
총 3개의 세션으로 아래와 같이 구성되어 있었습니다.

1. 행사 일정

시간

윈도우 커널 이야기

실행파일 분석기법

윈도우 드라이버 이야기

13:00 ~ 13:25

세미나실 입장

13:25 ~ 13:30

개회사 및 강사 소개

13:30 ~ 15:00

1. Windows Interrupt의 비밀
2. Windows I/O의 비밀-1

1. PE 구조 학습

1. USB 장치와 디바이스 스택 분석

15:00 ~ 15:30

Break Time

15:30 ~ 17:00

2. Windows I/O의 비밀-2
3. Windows Socket의 비밀

2. 디버깅 툴을 이용한 실행파일 분석

2. USB Request Packet(USBDI) 분석과 IRP

17:00 ~ 17:20

Q & A

17:40 ~

세미나 뒷 이야기 


원래 계획은 동아리 동기와 후배들 모두 참가하여, 각각 하나의 세션을 듣고나서 다시금 우리들끼리 작은 세미나를 갖자는 목표로 참가하였는데 약간의 miss가 생겨버렸습니다.

다름 아닌, 모두다 세미나 시간이 되도 안오길래 전화를 해봤더니 그제서야 일어나 버린것입니다. ㅡ0ㅡ;;

그래서 동기에게는 강요하지 않았고, 후배들에게는 생각보다 다른 세션이 좋은 내용이 많아서 듣기를 권장하여 뒤늦게라도 도착하여 듣게 되었습니다.

전 3개의 세션들 모두 다 듣고 싶었지만, 몸이 한개인지라 USB디바이스 드라이버쪽을 들었습니다. 사실 디바이스 드라이버에 대한 지식은 거의 문외한이라고 해도 과언이 아니지만, 예전 방학때 동아리 선배가 강의해주셨던 그 기억과 내용들이 그나마 이번 강의를 듣는데 있어서 엄청난 도움이 되었습니다.

하지만 워낙 어려운 내용들과 함께 너무나도 짧은 시간에 대량의 내용들을 습득, 이해하기에는 조금에 무리가 있었던건 사실입니다. 그래서 지금도 최대한 기억을 되살리고 있는중입니다. ^^ 그래서 아마도 글 쓴 내용들 중에는 엉뚱한 부분이 있을 수도 있습니다.;;

일단 시작전에 이봉석 선배님이 3~4시간안에 USB드라이버에 대한 내용을 모두다 강의하긴 어렵고, 아마 개요정도가 되지 않을까 싶다고 말씀하셨습니다.
사실 저한테는 오히려 이런 개요가 더 좋을 수 있을거란 생각을 해봤습니다. 아무것도 모르는 사람이 기술적인 것을 바로 보는것보다 가이드라인을 잡을 수 있는 편이 더 나을거란 생각말입니다. 하지만 실상 내용은 결코 쉽지 않았습니다. 어느정도는 이해가 갔지만, 점점 H/W적인부분의 내부로 들어갔던 부분에 대해서는 많이 와닿지는 않았습니다.

일단 제일 처음 USB드라이버 강의에 들어가면서 USB가 관여하는 부분에 있어서 H/W부분과 S/W부분을 나눠서 설명해주셨습니다.
S/W부분에서 USB드라이버를 제어하기위해 개발자가 만드는 부분은 Client Driver정도라고 하셨습니다. 나머지 부분들은 이미 MS에서 제공을 하고 있다고 했습니다.

그 다음으로 가장 중요한 부분이 바로 USB열거자와 PNPID라고 합니다..

USB열거자는 새로운 장치를 찾은 경우, 자신만의 고유한 방식(VID, PID)을 사용하여 새롭게 찾은 장치에 대한 고유한 PNPID를 윈도우게 등록하게 됩니다.

PNPIDHardwareIDCompatibleID등의 종류를 가지게 되며, 각각의 ID모두를 등록 할 필요는 없으며, 2가지 이상의 PNPID가 등록될 수 있다고 합니다.

USB열거자(USBHUB.SYS)는 장치(Device)의 ID를 들어내는 역할을 합니다.
HardwaredID : USB\VID_1234&PID_5678
HardwaredID : USB\VID_1234&PID_5678&MI_00
CompatibleID : USB\Class_01&SubClass_02
CompatibleID : USB\Class_03
CompatibleID : USB\Class_FF&SubClass_FF&Prot_00

위와 같은 HardwareID, CompatibleID 유형을 하고 있습니다.
여기서 중요한 부분이 바로 HardwareID 2개의 차이가 중요하다고 하셨습니다.
위 2개의 차이점은 MI_00이 있고 없고의 차이입니다.

여기서 MIMutil Fucntion Interface 라고 합니다.
이 말은 보통 USB장치가 하나의 작업만 하는 것이 아니라 다수의 작업을 하기위해 구성된 복합장치일 때 구별하기 위한 부분이라고 생각하면 될 것입니다.

HardwareID는 VID(VendorID), PID(ProductID)를 사용하여 생성한다.
CompatibleID는 Interface Class, SubClass를 사용하여 생성한다.

아 오늘은 여기까지 글을 써야겠습니다. 너무나도 졸린 나머지, 계속해서 강의때 들었던 내용들을 되새김질 하며 글을 쓰도록 하겠습니다.
728x90
posted by acedon
2008. 8. 20. 15:23 과거 저장소/Device Driver
728x90
오늘 노트북이 잠시 입고된 상태라 데스크 탑에 WDK를 설치한 후 간단한 드라이버를 빌드하려고 하였습니다. 그런데 이상하게 빌드 오류가 났습니다.
일단 오류 내용은 아래와 갔습니다.

Build Error Message

이런 메시지는 처음 보는 부분이라 급당황 했습니다. 그래서 WDK도 새로 설치해보고 혹시 소스상 문제일까 해서 다른 잘되는 소스로도 테스트 해보았지만 동일한 증상이였습니다.

그리고 나서 이것저것 구글도 뒤져보다가 결국 선배한테 물어봤는데, 의외로 간단히 답이 나왔습니다. 실로 민망할정도의 답이였습니다. ㅠ.ㅠ
전 왜 이런것도 모르고 드라이버 공부한다고 했을까? 하는 생각이 들정도였습니다.

원인소스 경로에 한글과 빈칸이 들어가 있었던 것이였습니다;;;

소스 경로에는 한글을 쓰면 안되고 또한 빈칸 또한 들어가면 안된다는 것을 알고 다시 테스트 해보니 정말 거짓말 처럼 잘되었습니다. 무슨 설정상의 문제도 아니였고, 소스상의 오류도 아닌 이런 간단한 오류 하나도 처리못한 제가 너무 미웠습니다.

그래도 이제 시작하는 입장에서 부끄럽지만 인정하고, 다시금 열심히 공부해야겠다는 생각을 하고 다시 전념하려 합니다.^^
728x90
posted by acedon
2008. 8. 12. 18:01 과거 저장소/Device Driver
728x90

이번에는 IRP(I/O Request Packet)에 대해서 알아보겠습니다.
처음 공부하는 입장이라 용어들이 매우 낯설게 느껴집니다. 그래도 계속해서 보고, 또 다른부분을 보다가도 눈에 띄이다 보니 자연스레 조금은 친숙해지는것 같습니다.

IRP(I/O Request Packet)
Windows2000이상의 OS에서 거의 모든 I/O는 패킷 구동 방식으로 이루어집니다. 개별적인 I/O요청은 각각 드라이버가 무엇을 해야 할지를 말하고, I/O 서브시스템을 통한 요구 처리 과정을 추적하는 작업 지시의 형태로 구현됩니다. 이런한 작업 지시들은 I/O Request Packet(IRP)라는 데이터 구조체 형태로 이루어집니다.

IRP처리과정

  1. I/O를 위한 사용자 모드 각각의 요구에 따라 I/O 관리자는 하나의 IRP를 nonpaged 시스템 메모리에 할당한다. I/O관리자는 파일 핸들과 사용자에 의해 요청된 I/O함수를 기반으로 IRP를 적절한 디바이스 드라이버의 Dispatch 루틴으로 전달합니다.
  2. Dispatch 루틴은 요청에 대한 Parameter를 체크하고, 만약 유효하다면 그 IRP를 드라이버의 Start I/O루틴에 전달합니다.
  3. Start I/O 루틴은 IRP의 내용을 이해하여 디바이스의 동작을 시작합니다.
  4. 동작이 완료되었을 때 드라이버의 DpcForlsr 루틴은 IRP에 최종상태 코드를 저장하고 이를 I/O 관리자에게 전달합니다.
  5. I/O 관리자는 IRP의 정보를 이용하여 그 요구를 완료하고 최종 상태를 사용자에게 보냅니다.

참고
  IRP 이름에서 혼동되는 부분이 발생 될 수 도 있습니다. 소켓도 아닌 커널모드 프로그램인데 패킷을 주고 받는것이 그렇습니다. 이는 NT설계자들이 운영체제의 견고성과 신뢰성을 위해 핵심 구현(Subsystem구조)을 클라이언트-서버 구조로 개발하였기 때문이라고 합니다. 



IRP Layout
하나의 IRP는 가변의 크기의 구조체이며, 이는 nopaged pool에 할당됩니다.
아래의 그림과 같이 크게 2부분(헤더, 스택: 하위 요청파리미터)으로 구성됩니다.

사용자 삽입 이미지

<IRP가 메모리에 로드되었을 때 구조>

IRP Header
  IRP Header 영역은 전체 I/O 요구에 대한 다양한 정보를 가지고 있습니다. 이 헤더 정보를 드라이버에서 직접 접근할 수 도 있고, 이와 반대로 다른 부분은 I/O관리자에 대해 배타적 특성을 가질 수 있습니다.

  • 입력을 읽고 출력을 쓸 수 있는 버퍼가 있습니다.
  • 현재 드라이버가 소유하는 IRP 메모리 영역을 가지고 있습니다.
  • 현재 드라이버가 소유하는 IRP에 대해서 운영체제가 취소를 호출 했을 때 동작하는 루틴이 있어야합니다.
  • 하위 요청(sub-request)에 대한 파라미터가 있습니다.
  • IRP Header는 특정 데이터에 대해서 추가 포인터를 가질 수 있습니다.

위 IRP 구조체 필드 중에서 중요한 부분에 대해서 정리한 표이다.

사용자 삽입 이미지

이제 어느정도 IRP에 대해서 알아본듯 합니다.
결코 쉽지 않은 용어들로 즐비하지만 포기하지 않고 꾸준히만 한다면 승산이 있을 것이라고 생각합니다.

출처 : 마이크로소프트웨어 2006년 4월 기사
728x90
posted by acedon
2008. 8. 12. 14:46 과거 저장소/Device Driver
728x90
NTSTATUS
DriverEntry(
 IN PDRIVER_OBJECT pDriverObject,
 IN PUNICODE_STRING puszRegistryPath
 )
{
 ...
 return (STATUS_SUCCESS)
}

위 구조는 가장 기본적인 DriverEntry()라는 EntryPoint, 즉 시작점입니다.
DriverEntry()함수 내에 2개의 인자가 있습니다.
그 중에 PDRIVER_OBJECT pDriverObject라는 인자 값이 있습니다.
DriverObject의 포인트이고, DriverObject의 구조체를 보겠습니다.

typedef struct _DRIVER_OBJECT {
    CSHORT Type;
    CSHORT Size;
    //
    // The following links all of the devices created by a single driver
    // together on a list, and the Flags word provides an extensible flag
    // location for driver objects.
    //
    PDEVICE_OBJECT DeviceObject;
    ULONG Flags;
    //
    // The following section describes where the driver is loaded.  The count
    // field is used to count the number of times the driver has had its
    // registered reinitialization routine invoked.
    //
    PVOID DriverStart;
    ULONG DriverSize;
    PVOID DriverSection;
    PDRIVER_EXTENSION DriverExtension;
    //
    // The driver name field is used by the error log thread
    // determine the name of the driver that an I/O request is/was bound.
    //
    UNICODE_STRING DriverName;
    //
    // The following section is for registry support.  Thise is a pointer
    // to the path to the hardware information in the registry
    //
    PUNICODE_STRING HardwareDatabase;
    //
    // The following section contains the optional pointer to an array of
    // alternate entry points to a driver for "fast I/O" support.  Fast I/O
    // is performed by invoking the driver routine directly with separate
    // parameters, rather than using the standard IRP call mechanism.  Note
    // that these functions may only be used for synchronous I/O, and when
    // the file is cached.
    //
    PFAST_IO_DISPATCH FastIoDispatch;
    //
    // The following section describes the entry points to this particular
    // driver.  Note that the major function dispatch table must be the last
    // field in the object so that it remains extensible.
    //
    PDRIVER_INITIALIZE DriverInit;
    PDRIVER_STARTIO DriverStartIo;
    PDRIVER_UNLOAD DriverUnload;
    PDRIVER_DISPATCH MajorFunction[IRP_MJ_MAXIMUM_FUNCTION + 1];
} DRIVER_OBJECT;
typedef struct _DRIVER_OBJECT *PDRIVER_OBJECT;

15개의 필드 중에 대략 3개정도가 가장 중요합니다.
  - DriverExtension
  - DriverUnload
  - MajorFunction

DriverExtension
  - PDRIVER_EXTENSION 구조체인데 이 구조체 중에서 AddDevice란 필드에 대해서 꼭 알아야 합니다.
DriverUnload
  - 드라이버를 Unload할 때 실행시킬 함수를 저장하기 위한 필드입니다.
MajorFunction
  - 커널의 I/O System 중 IO Manager라는 것이 있는데, IO Manager가 발생한 IRP패킷에 대해서 처리하는 함수입니다.
  - IRP(Input Output Request Packet)란 입출력을 요구할 때 발생시키는 데이터 형식이며, 총 28가지가 있습니다.

Driver실행 단계
  1. OS의 드라이버 로더가 .sys파일을 로드
  2. DriverObject를 생성(IO Manager가 처리)
  3. DriverObject가 할 일들을(IRP 핸들러 등록)지정
  4. Unload 및 AddDevice의 할 일들을 지정

IO Manager는 DriverObject에게 요청한 패킷을 전달하는 것이 아니고, DriverObject의 DeviceObject를 생선된 것에 IO 패킷을 요청합니다.

그리고 DeviceObject를 연결하여 DeviceStack을 만드는데 이 DeviceStack을 형성하여 장치를 컨트롤 하게됩니다.

출처 : 마이크로소프트웨어 2006년4월 기사

728x90
posted by acedon
2008. 8. 8. 20:09 과거 저장소/Device Driver
728x90
앞으로 짬짬이 시간을 내어서 Art Baker와 Jerry Lozano의 저서 The Windows 2000 Device Driver Book의 내용을 보면서 중요한 부분들은 메모하려고 합니다.
물론 위 원서를 읽으면 좋겠지만, 저는 그 번역서인 원리와 예제로 배우는 Windows 2000 디바이스 드라이버를 읽어 보고 있는 중입니다. ^0^

Windows2000 드라이버의 종류는 무엇이 있는지 살펴보겠습니다.

- Windows2000은 가장 상위에 사용자 모드커널 모드 두 가지 타입의 드라이버를 제공합니다.


1. 사용자 모드 드라이버는 사용자 모드에서 동작하는 시스템 레벨의 코드입니다.
  - 사용자 모드 드라이버에는 가상의 하드웨어 or 새로운 환경 서브시스템을 위한 가상 드라이버들이 있습니다.
  - Windows2000에서는 사용자 모드의 코드는 직접적으로 H/W에 접근 할 수 없으므로 필수적으로 커널 모드
    드라이버 코드에 의해야 합니다.

2. 커널 모드 드라이버는 커널 모드에서 동작하는 시스템 레벨의 코드입니다.
  - 커널 모드에서는 H/W에 접근하는 것이 허용되므로, 직접적으로 H/W를 제어할 수 있습니다.

이제 우리가 배우려고 하는 부분은 H/W를 다루기 위한 커널 모드 드라이버 부분이니 이 부분에 대해서 더 깊숙히 들어가 보겠습니다.

- 커널 모드 드라이버에는 레가시(Legacy)드라이버WDM드라이버의 이 두가지 타입으로 구분되어집니다.


1. 레거시(Legacy)드라이버는 위 책에 첫 번째 판에 잘 나와있다고 합니다.
  - 하지만 궁금하여 찾아보니 "미친감자"님이 쓰신 내용이 있어서 짧막하게나마 설명 하려 합니다.
    Legacy Driver란?
      - Legacy Driver란 NT4.0 계졀 규격에 맞는 드라이버를 지칭한다고 합니다.
      - WDM Driver와 구분하기 위해서 Legacy Driver라고 말한다고 합니다.
      - Legacy란 영어 단어의 의미에서 부터 유산이란 의미기기에 Windows2000입장에서는 NT4.0의 드라이버
        형태는 유산과 같다고 생각할 수 있기에 그런 단어를 붙인거 같다고 합니다.

2. WDM 드라이버는 플러그 앤 플레이를 지원하고, 전원관리, 자동 설정(autoconfiguration) 그리고 핫 플러그인기능을 제공합니다.
  - WDM 드라이버가 제대로 작성되었다면 Windows2000과 Windows98에 동시에 사용될 수 있습니다.
  - 하지만 두 운영체제 사이에 호환성은 보장하지 않습니다.

- 레거시 드라이버와 WDM 드라이버는 또 다른 레벨의 형태로 상위레벨, 인터미디엇, 하위레벨로 분류 할 수 있다.


1. 상위 레벨 드라이버에는 파일 시스템 드라이버(FSD)가 해당된다.
  - 파일 시스템 드라이버는 상위 레벨에서 내려온 요청을 특정 디바이스의 요청에 맞게 변환하는 역할을 수행합니다.

2. 인터미디엇(Intermediate)드라이버는 디스크 미러 드라이버, 클래스 드라이버, 미니드라이버 그리고 필터 드라이버들이 해당됩니다.
  - 이러한 드라이버들은 상위 레벨의 드라이버와 하위 계층 드라이버 사이에 위치하여 변환하는 역할을 수행합니다.

3. 하위 레벨 드라이버들은 H/W BUS를 위한 컨트롤러 드라이버들이 해당됩니다.
  - 예로, SCSI 호스트 버스 어댑터(SCSI Host Bust Adapter)는 하위 레벨 드라이버중 하나입니다.
  - 이런 드라이버들은 Windows2000의 HAL계층과 상호 동작하기도 하고, H/W와 직접 통신하기도 합니다.

위 내용들을 한눈에 확인 할 수 있게 도표를 참고 하시기 바랍니다.
사용자 삽입 이미지

Windows2000 드라이버 분류 계층도

728x90
posted by acedon
2008. 7. 27. 22:50 과거 저장소/Device Driver
728x90

디바이스 드라이버 스터디 1일차

주제
  - 드라이버 개발 환경 구성
  - WinDBG를 이용한 유저모드 디버깅
  - WinDBG를 이용한 커널모드 디버깅
  - 초 간단 드라이버 제작

invalid-file

요약본 받기

728x90
posted by acedon
2008. 7. 23. 15:39 과거 저장소/Device Driver
728x90

제부터 이 카테고리의 내용은 모두 디바이스드라이버(DeviceDriver)라는 내용으로 채워질 것이며, 채워 나갈것이다. 그 내용의 양과 질은 전적으로 나의 몫이니 ...
 

나이 24세, 군 제대 후 현재 3학년,
1학년 때의 과거를 회상해 본다.

 디바이스드라이버라는 말을 대학와서 처음들어보게 되었다.
그게 그럴 수 밖에 없는게 우리 서울산업대학교 컴퓨터 공학과 내 EnlessCreation(이하EC)라는 동아리는 디바이스드라이버라는 분야에서 내놓으라는 분들이 계셨던 곳이라서 간간히 접할수 있었던 것이다.

지만 그 이제 막 들어온 신입생들이 무슨 내용인줄 알아겠나, 그냥 우와~ 라는 생각만 가졌던것 같다.
그렇게 학교생활은 그저 학교 커리큘럼 흐름에만 묻혀서 다니다보니 지금의 여기까지 오게 되었다.
지난 3년 동안을 뒤돌아 보면 정말 나는 그야 말로 "뭐 한게 없다"라는 말이 딱 맞는것 같다.
그냥 그냥 학교 과목만 듣고 하루하루 허비했다는 생각에 현재 나는 몹쓸 자책감에 빠져있다.

실 현재에 있는 어플리케이션을 만드는 부분에 있어서는 그다지 흥미가 생기지는 않는다. 그렇다고해서 내가 하고 싶은대로 다 만들수 있는 실력에는 근처도 가지도 못하고 있고, 노력 또한 별로 하지 않았다. 예전때에 그런 느낌이 없었다.그러는 과정에서 신입생 때 들었었던 DeviceDriver, SystemProgramming, Low-Level part등에 대한 관심이 조금씩 싹트기 시작했다.  하지만 그 기초라고 생각되는 내용에 접근하려 하니 그다지 쉽게 나에게 문을 열어주지 않는듯 보인다. 그런 부분이 또다시 나를 움직이게 하는 원동력이 될거라는 생각이 들었다.

과정에서 역시나 내 동기들도 같은 부분에 관심을 가지고 있어서 가는길이 외롭지는 않을듯 보인다.
또한 유능하신 선배님들이 많으셔서 더욱더 힘이 난다.

제부터 5주간 5번의 DeviceDriver특강을 EC 9기 최정현 선배님이 고생해주시기로 해서 천군만마를 얻은듯하여 매우 기뻤다. 정말 이제부터 시작인듯 보인다. ! 열심히 해야지

혹시라도 관심을 가지시고 접해보시려고 하시는 분들이 있다면 현재 특강(스터디) 진행 사항을 구글그룹에 올려놓고 있으니 참고 하시기 바랍니다.

                                           DeviceDriver 접하러 가기
728x90
posted by acedon