나래온 툴 내부 구조 – 7. SATA 장치에서 상태 정보(SMART) 가져오기

필요성 사실 이 파트에서는 필요성을 굳이 설명할 이유가 있을까 싶다. 디스크 관리 도구의 존재 의의이기 때문이다. 제품의 수명을 관리하고, 사용자가 놓치기 쉬운 이상 증상들을 확인하는 일은 모두 여기서 시작된다. 따라서 이번 글에서는 글을 다른 구성으로 가고자 한다. S.M.A.R.T: 자가 진단, 분석, 보고 기술 이 기술은 이름이 말하는 대로, 저장 장치가 스스로 분석하고 진단해서 문제가 있는지 […]

나래온 툴 내부 구조 – 6. SATA 장치에서 기본 정보 가져오기

필요성 지난 시간에 ACS-3를 둘러보면서, 개념들과 SATA 장치에 어떻게 명령해야 하는지에 대한 방법을 살펴보았다. 이번 시간에는 나래온 툴에서 장치의 기본 정보를 얻어올 때 쓰는 명령어 구현을 살펴보자. Identify (Identify device) 4편에서 Identify에 대해 다음과 같이 설명한 적이 있다. BIOS나 장치 관리자에 나오는 장치 이름, 펌웨어 버전, 시리얼 번호, 용량 등은 다 여기서 가져오는 것이다. 요약하면, […]

나래온 툴 내부 구조 – 5. SATA 명령어 개요

필요성 NVMe 장치가 널리 퍼지긴 했지만, 여전히 SATA 장치는 저장장치의 대다수를 이루고 있다. SSD의 상당수가 SATA 인터페이스로 PC와 연결되며, HDD 역시 SATA로 연결된다. 따라서 이들의 정보를 가져오는 데에 이들의 언어인 ATAPI는 필수적이다. 나래온 툴 역시 모든 구현의 기준은 SATA이며, 다른 장치에서 나온 결과는 SATA 형식으로 변환을 거치게 하는 식으로 동작하고 있다. 리팩토링 당시에 SATA의 특징을 […]

나래온 툴 내부 구조 – 4. 명령 집합과 버퍼 해석

필요성 사람들이 이 블로그에 찾아오는 이유는 여기에 있을 가능성이 높다고 생각한다. Read, Write, Open, Close가 아닌 모든 명령어가 들어가는 곳, ioctl. 정확히는 윈도우에서 DeviceIoControl이라고 부르는 그 API다. 학부 시절에 잘 하면 존재 정도는 들었을 이 API로 모든 명령이 오간다. 나 역시 처음 들었을 때는 매우 막연해서 어디에서 자료를 찾아야 할지도 잘 몰랐다. 이 편부터는 그 […]

나래온 툴 내부 구조 – 3. 물리 드라이브 추상화

필요성 물리 드라이브 자체는 수많은 기능을 가지고 있다. 이들 중 나래온 툴에서 필요한 부분을 객체로 추상화한 것이 TPhysicalDrive이다. 내부를 보면 사실 이 객체는 요청들을 두 방향으로 전달만 하는데, 버스에 직접 요청하는 것(ATA, SCSI, NVMe, …)과 다른 API에 기반한 것들을 따로 관리하고 있다. 전자가 TBusPhysicalDrive, 후자가 TOSPhysicalDrive이다. 왜 인터페이스인가? 이 객체는 TPhysicalDrive 자체로 쓰이는 일은 없고 대부분 IPhysicalDrive […]

나래온 툴 내부 구조 – 2. 경로가 지정된 객체들

필요성 나래온 툴에는 경로가 필요한 객체들이 많다. 대표적으로 물리 드라이브 그 자체인 TPhysicalDrive부터, 수많은 Getter 객체들이 모두 해당 드라이브의 경로를 필요로 한다. 이외에도 파티션을 지정하는 객체의 경우에도 경로를 필요로 한다. 이 경우 각 행동을 수행할 때마다 경로를 기입하게 하는 것은 부자연스러울 뿐더러 혼동의 가능성이 매우 크다. 따라서 객체가 생성될 때 경로를 지정하고 내부에서 경로를 보관하게 […]

나래온 툴 내부 구조 – 1. 물리 드라이브 목록 가져오기

들어가기에 앞서 이 시리즈는 나래온 툴의 내부 구조를 정리하여, 해당 프로그램의 일부 기능을 구현하는 사람들에게 도움을 줄 목적으로 작성되었다. 따라서 이 글은 그동안 질문 받았던 부분을 중심으로 쓰게 될 것이다. 더 궁금한 점이 있으면 메일로 문의하면 된다. 다만 코드 스니펫의 델파이 -> C++ 번역 요청은 받지 않는다. 필요성 디스크 툴이 처음 시작할 때 가장 먼저 하는 […]

리팩토링 대작전 – 3. 효용

상당히 귀찮은 작업이었지만 효용도 만만찮았다. 여기서는 리팩토링으로 얻어진 장점들을 논해보려 한다. 분석 편의성 일단 디버그/프로파일링 시에 필요한 분석이 매우 편해졌다. 무료 툴들의 경우는 으레 함수 단위로 분석을 해주는데, 이렇게 한 가지 일만 하게 되면 함수만 알려줘도 어떤 부분이 문제가 되는지 알 수 있기 때문이다. 또한 디버그의 경우에도 스택에 올라간 함수들 이름만 따서 줄글로 이으면 뭘 […]

리팩토링 대작전 – 2. 부수고 또 부수고

시작하자마자 부수고 또 부수었다. 기존 코드를 ‘한 가지만 하는’ 함수로 나누다 보니 객체가 자연스레 생겼다. 그 객체 수가 불어나며 그를 묶어낼 패키지도 자연스레 정의되었다. 이 시기 ‘델파이 프로그래밍 언어‘가 나의 친구였다. C 프로그래밍 언어를 읽어보면서, 각 언어의 레퍼런스로 창시자가 내놓은 일명 ‘XX 프로그래밍 언어’가 정말 좋음을 이 때 깨달았다. 그래서 산 책인데, 이를 통해 10년 […]

1% 개발, 99% 유지보수 – 5. 에필로그

그 후로 나는 군대에 당첨되었고, 그러고도 많은 일이 있었고, 남아있는 수많은 일을 뒤로 하고 국방의 의무를 수행하기 위해 떠났다. 어느새 나래온 툴은 처음의 앳된 모습에서 점점 자신을 꾸밀 줄 아는 모습으로 변해갔으며, 내가 만든 다른 유틸리티들의 든든한 토대가 되어 더티 테스트 툴의, 그리고 수명 테스트 툴이 뿌리를 박을 수 있도록 도와주었다. 오늘도 수많은 프로그램들이 그 […]