내가 뒤집을 때libdevmapper.h장치 매퍼 ioctl을 올바르게 사용하는 방법(또는 대신 libdevmapper를 사용하는 방법)에 대한 단서, 코드가 여기에 있는 이유가 혼란스럽습니다.나무 생성/관리그리고해시 테이블.
libdevmapper가 기본 장치 매퍼 ioctl에 대한 인터페이스를 제공하는 경우 여기에 데이터 구조를 포함시키는 동기는 무엇입니까? 게다가, 커널이 이미 모든 장치 매핑을 관리하기 위한 데이터 구조를 갖고 있다면,추상적인라이브러리 수준 데이터 구조는 기껏해야 실제 정보의 캐시된 버전입니다.
나는 장치 매퍼, 커널 코드 및 시스템 호출을 처음 접한다는 점을 명심하십시오. 내가 여기서 무엇을 놓치고 있는 걸까요?
답변1
이것은 매우 일반적인 답변입니다. 저는 해당 헤더 파일을 읽지도 않았다는 것을 인정합니다. (자세한 코드 질문을 하고 싶다면,스택 오버플로올바른 장소입니다. )
데이터 구조가 프로그램(또는 동일한 프로그램의 다른 부분)이 통신하는 방식이라는 점을 무시하고 있는 것 같습니다. 통신의 각 당사자는 데이터 구조를 이해해야 합니다. 그렇지 않으면 메시지를 이해하기 어려울 것입니다.
예를 들어 커널의 struct stat일부 헤더 파일 어딘가에 정의가 있습니다. 귀하의 프로그램에는 glibc에서 제공하는 다른 헤더의 헤더도 있습니다(비록 커널에서 복사할 수도 있음). 파일 정보를 얻기 위해 시스템 호출을 사용하면 stat이를 커널에 전달합니다 struct stat. 커널은 해당 데이터 구조를 정보로 채웁니다. 그러면 프로그램이 이 정보를 읽습니다. 프로그램은 데이터 구조를 사용하여 커널과 통신합니다.
또 다른 예로, struct stat *프로그램의 다른 함수(예: 표시를 담당하는 함수)에 이를 전달하면 프로그램은 데이터 구조를 사용하여 자체의 두 부분 간에 통신한 것입니다.
따라서 libdevmapper의 트리 및 해시 테이블 구현과 일반적으로 커널 함수 라이브러리 헤더의 데이터 구조는 여러 가지 목적 중 하나 이상을 제공합니다.
- 이는 라이브러리가 커널과 통신하는 방식입니다.
- 이는 라이브러리가 프로그램과 통신하는 방식입니다.
- 라이브러리 개발자는 라이브러리가 프로그램에 유용하다고 생각하며(예: devmapper 상태 추적), 너무 작거나 너무 커지지 않고 포함될 수 있을 만큼 밀접하게 관련되어 있다고 생각합니다.