맨위로가기

Ioctl

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

ioctl은 운영 체제에서 하드웨어 장치를 제어하기 위한 시스템 콜 인터페이스이다. 사용자 공간과 커널 공간 간의 통신을 가능하게 하여, 장치 드라이버에 특정 요청을 전달하고 장치를 구성하는 데 사용된다. 유닉스 및 Win32 시스템에서 널리 사용되며, 터미널 제어, 커널 확장, 하드웨어 장치 구성 등 다양한 기능을 제공한다. ioctl은 복잡성과 보안 문제를 야기할 수 있으며, 넷링크, 메모리 매핑과 같은 대안이 존재한다.

2. 배경

운영 체제는 사용자 공간과 커널이라는 두 가지 영역으로 나뉜다. 문서 편집기와 같은 일반적인 응용 프로그램은 사용자 공간에서 실행되는 반면, 네트워크 스택과 같이 운영 체제의 핵심적인 부분은 커널에서 실행된다. 커널은 중요한 시스템 자원을 관리하고, 응용 프로그램 사이에 보안 및 신뢰성을 보장하는 역할을 한다. 따라서 일반적인 응용 프로그램은 커널 자원에 직접 접근할 수 없도록 제한된다.[1]

사용자 공간의 응용 프로그램은 시스템 콜이라는 특별한 방법을 통해 커널의 기능을 사용한다. 시스템 콜은 각 기능마다 고유한 번호가 매겨져 있으며, 응용 프로그램은 이 번호를 이용하여 원하는 기능을 요청한다. 예를 들어, "exit"은 1번, "write"는 4번과 같이 시스템 콜 번호가 지정되어 있다. 운영 체제는 이러한 방식으로 수백 가지의 시스템 콜을 제공한다.[1]

하지만 시스템 콜은 일반적인 기능에는 편리하지만, 특수한 하드웨어 장치에는 적합하지 않을 수 있다. 대부분의 하드웨어 장치는 커널에서만 직접 접근할 수 있는데, 사용자 프로그램이 장치와 직접 통신해야 하는 경우가 발생할 수 있다. 예를 들어, 관리자가 이더넷 인터페이스 설정을 변경해야 하는 경우가 있을 수 있다. 최신 운영 체제는 매우 다양한 장치를 지원하고, 그 기능 또한 매우 다양하여 운영 체제 개발자가 모든 장치의 기능을 예측하고 시스템 콜로 제공하는 것은 불가능하다.

이러한 문제를 해결하기 위해 '''ioctl'''이라는 인터페이스가 등장했다. ioctl은 모든 장치 드라이버가 공유하는 단일 시스템 콜을 제공하여, 다양한 장치에 대한 요청을 처리할 수 있게 한다. 이를 통해 커널은 복잡한 시스템 콜 테이블을 만들 필요 없이 유연하게 장치와 통신할 수 있다. ioctl은 사용자 공간에서 장치 드라이버와 통신할 수 있게 해주는 시스템 콜이며, 장치 드라이버에 대한 요청은 일반적으로 장치 핸들과 요청 번호로 ioctl 시스템 콜과 함께 전달된다.

2. 1. 사용자 공간과 커널 공간

응용 프로그램 코드는 사용자 공간에, 네트워크 스택과 같은 운영 체제의 기반 기능은 커널에 위치한다. 커널 코드는 민감한 리소스를 관리하고 응용 프로그램 간의 보안 및 신뢰 장벽을 제공한다. 이러한 이유로 사용자 모드 응용 프로그램은 CPU에 의해 커널 리소스에 직접 접근하는 것이 금지된다.[1]

사용자 공간 응용 프로그램은 시스템 콜을 통해 커널에 요청을 보낸다. 시스템 콜은 보통 시스템 콜 벡터와 함께 추가되며, 여기서 요청자는 원하는 시스템 콜을 색인 숫자로 기록한다. 예를 들어, "exit"은 시스템 콜 1, "write"는 시스템 콜 4가 될 수 있다. 시스템 콜 벡터와 색인은 요청을 관리하기 위해 커널 기능을 살피는 데 쓰인다. 이런 식으로 운영 체제는 보통 수백 개의 시스템 콜을 제공한다.[1]

2. 2. 시스템 콜의 한계와 ioctl의 등장

시스템 콜은 표준 커널 기능에 접근하는 데 편리하지만, 비표준 하드웨어 주변 장치에는 적합하지 않을 수 있다. 대부분의 하드웨어 주변 장치(장치)는 커널 내에서만 직접 접근할 수 있지만, 사용자 코드가 장치와 직접 통신해야 하는 경우가 있을 수 있다. 예를 들어, 관리자는 이더넷 인터페이스의 미디어 유형을 구성해야 할 수 있다. 최신 운영 체제는 다양한 장치를 지원하며, 그 중 많은 수가 사용자에게 보이는 세세한 인터페이스를 제공하지만, 운영 체제 제공 업체가 모든 장치를 알 수는 없다. 따라서 커널이 장치 사용을 위한 시스템 콜을 제공하기 어려워진다.

'''Ioctl''' 인터페이스는 모든 장치 드라이버가 공유하는 하나의 시스템 콜을 할당함으로써 이 문제를 해결한다. 이 시스템 콜을 통해 다양한 장치의 특정한 요청을 전달할 수 있다. 즉, 커널은 관리하기 어려운 시스템 콜 테이블을 만들지 않고도 유동적으로 장치에 대한 호출을 처리할 수 있다. `ioctl`은 사용자 공간에서 장치 드라이버와 통신할 수 있게 해주는 단일 시스템 콜이며, 장치 드라이버에 대한 요청은 일반적으로 장치 핸들과 요청 번호로 이 `ioctl` 시스템 콜과 관련하여 벡터화된다.

3. 기능

`ioctl`은 하드웨어 장치 구성, 터미널 제어, 커널 확장 등 다양한 용도로 사용되는 시스템 호출이다.


  • 하드웨어 장치 구성: Win32 시스템에서 `ioctl` 호출은 USB 장치와 통신하거나 저장 장치의 정보를 얻는 데 사용된다.
  • 터미널 제어: 유닉스 계열 운영 체제에서 `ioctl`은 화면 크기 설정, 문자 스트림 푸시 등 터미널 제어 및 구성에 사용된다.
  • 커널 확장: `ioctl`은 사용자 공간 코드와 커널 확장을 연결하는 방법을 제공한다.

3. 1. 하드웨어 장치 구성

`ioctl`의 일반적인 사용 사례는 하드웨어 장치를 제어하는 것이다.

예를 들어, Win32 시스템에서 `ioctl` 호출은 USB 장치와 통신하거나 연결된 저장 장치의 드라이브 지오메트리 정보를 검색할 수 있다.

OpenBSD 및 NetBSD에서는 `ioctl`이 `bio(4)` 의사 장치 드라이버와 `bioctl` 유틸리티에 의해 사용되어 `ifconfig`와 유사한 통합된 벤더에 관계없는 인터페이스에서 RAID 볼륨 관리를 구현한다.[1][2]

NetBSD에서는 `ioctl`이 `sysmon` 프레임워크에서도 사용된다.[3]

3. 2. 터미널 제어

유닉스 계열 운영 체제에서 ioctl은 터미널 (가상 터미널 포함)을 제어하고 구성하는 데 사용된다. 예를 들어, `TIOCSWINSZ` 호출을 사용하여 디스플레이 크기를 설정할 수 있다. TIOCSTI (터미널 I/O 제어, 터미널 입력 시뮬레이션) ioctl 함수는 문자를 장치 스트림에 푸시할 수 있다.[4]

3. 3. 커널 확장

커널 확장은 파일 시스템에서 이름으로 열 수 있는 위치를 제공하며, 이를 통해 임의의 수의 `ioctl` 호출을 전송하여 운영 체제에 시스템 호출을 추가하지 않고 확장을 프로그래밍할 수 있다.

3. 3. 1. sysctl 대안

OpenBSD 개발자에 따르면, `ioctl`과 `sysctl`은 커널을 확장하는 두 가지 시스템 호출이며, `sysctl`이 더 간단할 수 있다.[5]

NetBSD에서 하드웨어 모니터링을 위한 `sysmon_envsys` 프레임워크는 `proplib`을 통해 `ioctl`을 사용한다. 반면 OpenBSD와 DragonFly BSD는 해당 `hw.sensors` 프레임워크에 `sysctl`을 사용한다. NetBSD의 `envsys` 초기 버전은 `proplib`을 사용하기 전에 `ioctl`로 구현되었으며, 이 프레임워크가 실험적이며 `sysctl(8)` 인터페이스가 개발되어 대체되어야 함을 시사하는 메시지가 있었다.[6][7] 이는 2003년 OpenBSD에서 `sysctl`을 선택하고 `hw.sensors`를 도입한 것을 설명할 수 있다. 그러나 2007년 `envsys` 프레임워크가 `proplib`을 중심으로 재설계되었을 때 시스템 호출은 `ioctl`로 유지되었고, 해당 메시지는 삭제되었다.[8]

4. 구현

운영 체제는 사용자 공간과 커널이라는 두 가지 계층으로 나뉜다. 문서 편집기와 같은 응용 프로그램은 사용자 공간에, 네트워크 스택과 같은 운영 체제의 기반 코드는 커널에 있다. 커널 코드는 민감한 리소스를 관리하고 응용 프로그램 간의 보안 및 신뢰 장벽을 제공한다. 따라서 사용자 모드 응용 프로그램은 CPU에 의해 커널 리소스에 직접 접근하는 것이 제한된다.

사용자 공간 응용 프로그램은 시스템 콜을 통해 커널 모드로 전환하여 커널의 기능을 요청한다. 시스템 콜은 시스템 콜 벡터와 함께 제공되며, 요청자는 원하는 시스템 콜을 색인 숫자로 기록한다. 예를 들어, "exit"은 시스템 콜 1, "write"는 시스템 콜 4가 될 수 있다.

시스템 콜은 편리하지만, 드라이버 장치를 제어하는 데는 한계가 있다. 대부분의 하드웨어 주변 기기는 커널 안에서만 직접 접근해야 하지만, 사용자 코드가 장치와 통신해야 하는 경우가 있다. 예를 들어, 관리자는 이더넷 인터페이스의 미디어 종류를 구성해야 할 수 있다. 현대 운영 체제는 다양한 장치를 지원하지만, 모든 장치가 운영 체제 제공 업체에 알려진 것은 아니다. 따라서 장치 API를 제공하기 위해 고정된 시스템 콜 숫자를 사용하는 것은 어렵다.

'''Ioctl''' 인터페이스는 모든 장치 드라이버가 공유하는 하나의 시스템 콜을 할당하여 이 문제를 해결한다. 이 시스템 콜을 통해 다양한 장치의 특정한 요청을 처리할 수 있다. 따라서 커널은 관리하기 어려운 시스템 콜 테이블을 만들지 않고도 유동적으로 장치에 대한 호출을 처리할 수 있다.

`ioctl` 시스템 호출은 Version 7 Unix에서 `stty`[9] 및 `gtty` 시스템 호출을 대체하기 위해 처음 등장했으며, 다음과 같은 매개변수를 사용한다.


  • 열린 파일 디스크립터
  • 요청 코드 번호
  • 데이터에 대한 유형이 없는 포인터 (드라이버로 이동, 드라이버에서 반환 또는 둘 다).


커널은 일반적으로 `ioctl` 호출을 장치 드라이버로 직접 전송하며, 장치 드라이버는 필요에 따라 요청 번호와 데이터를 해석한다. 각 드라이버 작성자는 해당 드라이버에 대한 요청 번호를 문서화하고 이를 상수로 헤더 파일에 제공한다.

요청 번호는 일반적으로 요청이 의도된 장치 또는 장치 클래스를 식별하는 코드와 특정 요청을 나타내는 숫자를 결합한다. 장치 또는 장치 클래스를 식별하는 코드는 일반적으로 단일 ASCII 문자이다. 4.2BSD 및 이후의 BSD 릴리스, 해당 릴리스에서 파생된 운영 체제 및 리눅스를 포함한 일부 유닉스 시스템에는 장치 드라이버로 전송되거나 전송될 데이터의 크기와 데이터 전송 방향을 요청 번호 내에 인코딩하는 규칙이 있다.

이러한 규칙을 따르든 상관없이 커널과 드라이버는 이를 인식하지 못하는 드라이버에 대한 요청을 하는 응용 프로그램에 통일된 오류 코드(기호 상수 `ENOTTY`로 표시됨)를 제공하기 위해 협력한다. `ENOTTY`는 "타자기가 아님"과 관련되어 있으며, 텔레타이프(tty) 장치에서 유래되었다.

`TCSETS`는 시리얼 포트에서 `ioctl` 호출의 한 예이다. 시리얼 포트에서 일반적인 읽기 및 쓰기 호출은 데이터 바이트를 주고받지만, `ioctl(fd,TCSETS,data)` 호출은 특수 문자 처리 또는 포트의 출력 신호(예: DTR 신호)와 같은 다양한 드라이버 옵션을 제어한다.

Win32의 `DeviceIoControl`은 장치를 제어하는데 사용되며, 다음과 같은 매개변수를 사용한다.

  • 열린 객체 핸들 (파일 디스크립터에 해당하는 Win32)
  • 요청 코드 번호 ("제어 코드")
  • 입력 매개변수를 위한 버퍼
  • 입력 버퍼의 길이
  • 출력 결과를 위한 버퍼
  • 출력 버퍼의 길이
  • 겹쳐진 I/O를 사용하는 경우, `OVERLAPPED` 구조체


Win32 장치 제어 코드는 수행되는 작업의 모드를 고려하며, 장치 드라이버의 보안에 영향을 미치는 4가지 작동 모드가 정의되어 있다.

  • `METHOD_IN_DIRECT`: 버퍼 주소가 사용자 모드 호출자에 의해 읽을 수 있는지 확인한다.
  • `METHOD_OUT_DIRECT`: 버퍼 주소가 사용자 모드 호출자에 의해 쓸 수 있는지 확인한다.
  • `METHOD_NEITHER`: 사용자 모드 가상 주소가 매핑 또는 유효성 검사 없이 드라이버에 전달된다.
  • `METHOD_BUFFERED`: I/O 관리자가 제어하는 공유 버퍼가 데이터를 사용자 모드로 이동하는 데 사용된다.

4. 1. 유닉스

'''Ioctl''' 인터페이스는 모든 장치 드라이버가 공유하는 하나의 시스템 콜을 할당함으로써 장치 제어 문제를 해결한다. 유닉스에서 ioctl 호출은 다음의 매개 변수를 가진다.

# 열려 있는 파일 서술자

# 요청 코드 번호

# 드라이버 서명이 되지 않은 정수값, 또는 포인터

`ioctl` 시스템 호출은 `stty`[9] 및 `gtty` 시스템 호출을 대체하기 위해 Version 7 Unix에 처음 등장했으며, 추가 요청 코드 인수를 사용했다. 커널은 일반적으로 `ioctl` 호출을 장치 드라이버로 직접 전송하며, 장치 드라이버는 필요에 따라 요청 번호와 데이터를 해석한다. 각 드라이버 작성자는 해당 드라이버에 대한 요청 번호를 문서화하고 이를 상수로 헤더 파일에 제공한다.

요청 번호는 일반적으로 요청이 의도된 장치 또는 장치 클래스를 식별하는 코드와 특정 요청을 나타내는 숫자를 결합한다. 장치 또는 장치 클래스를 식별하는 코드는 일반적으로 단일 ASCII 문자이다. 4.2BSD 및 이후의 BSD 릴리스, 해당 릴리스에서 파생된 운영 체제 및 리눅스를 포함한 일부 유닉스 시스템에는 장치 드라이버로 전송되거나 전송될 데이터의 크기와 데이터 전송 방향을 요청 번호 내에 인코딩하는 규칙이 있다.

`TCSETS`는 시리얼 포트에서 `ioctl` 호출의 예이다. 시리얼 포트에서 일반적인 읽기 및 쓰기 호출은 데이터 바이트를 수신하고 전송한다. `ioctl(fd,TCSETS,data)` 호출은 이러한 일반적인 I/O와 별개로 특수 문자 처리 또는 포트의 출력 신호(예: DTR 신호)와 같은 다양한 드라이버 옵션을 제어한다.

4. 2. Win32

`DeviceIoControl` 함수는 장치를 제어하는 데 사용된다. 이 함수는 다음과 같은 매개 변수를 가진다.[11]

매개 변수설명
열려 있는 객체 핸들파일 디스크립터에 해당하는 Win32 핸들
요청 코드 번호제어 코드
입력 매개 변수를 위한 버퍼입력 데이터
입력 버퍼의 길이입력 버퍼 크기
출력 결과를 위한 버퍼출력 데이터
출력 버퍼의 길이출력 버퍼 크기
`OVERLAPPED` 구조체겹쳐진 I/O를 사용할 때 사용



Win32 장치 제어 코드는 수행되는 작업의 방식을 결정하며, 장치 드라이버 보안에 영향을 주는 4가지 작동 모드가 있다.


  • `METHOD_IN_DIRECT`: 버퍼 주소를 사용자 모드 호출자가 읽을 수 있는지 확인한다.
  • `METHOD_OUT_DIRECT`: 버퍼 주소를 사용자 모드 호출자가 쓸 수 있는지 확인한다.
  • `METHOD_NEITHER`: 사용자 모드 가상 주소가 매핑 또는 유효성 검사 없이 드라이버에 전달된다.
  • `METHOD_BUFFERED`: I/O 관리자가 제어하는 공유 버퍼가 데이터를 사용자 모드로 이동하는 데 사용된다.

5. 대안

장치 및 커널 확장 기능은 새로운 시스템 호출을 통해 사용자 공간에 연결될 수 있다. 그러나 운영 체제 개발자들이 시스템 호출 인터페이스를 집중적이고 효율적으로 유지하려고 하기 때문에 이러한 접근 방식은 거의 사용되지 않는다.

5. 1. 기타 벡터 호출 인터페이스

유닉스 운영 체제에서는 `fcntl` (파일 제어) 및 `setsockopt` (소켓 옵션 설정)와 같은 두 가지 벡터 호출 인터페이스가 널리 사용된다. `fcntl` 시스템 호출은 열린 파일을 구성하며, 논블로킹 I/O를 활성화하는 등의 상황에서 사용된다. `setsockopt` 시스템 호출은 열린 네트워크 소켓을 구성하며, BSD 유닉스 시스템에서 ipfw 패킷 방화벽을 구성하는 데 사용된다.

5. 2. 메모리 매핑

유닉스 및 Win32에서 장치 인터페이스 및 입출력 기능은 메모리 맵 파일을 사용하여 제공될 수 있다. 메모리 매핑은 장치와 사용자 공간 응용 프로그램 간의 대량 데이터 전송에 더 효율적이다.[1] 개별 `ioctl` 또는 read/write 시스템 호출은 사용자 공간에서 커널로 반복 전환되어 오버헤드가 발생하지만, 메모리 맵 주소 범위에 접근할 때는 이러한 오버헤드가 발생하지 않는다.[1]

5. 3. 넷링크 (Netlink)

넷링크는 ioctl의 보다 유연한 후계자로 설계된 프로세스 간 통신(IPC)을 위한 소켓과 유사한 메커니즘이다.

6. 영향

`ioctl` 호출은 커널 시스템 호출 인터페이스의 복잡성을 줄이지만, 사용자-커널 API 전체를 복잡하게 만들 수 있다. 수많은 `ioctl` 호출은 시스템 호출과 유사하지만 다른 전달 메커니즘을 갖는다.

응용 프로그램 개발자에게 시스템 호출과 `ioctl` 호출은 큰 차이가 없으며, libc 등의 라이브러리가 복잡성을 숨겨준다. Libpcap, libdnet 같은 라이브러리는 `ioctl` 인터페이스의 복잡성을 추상화한다.[2][3]

`ioctl` 호출 처리기는 링 0에 위치하므로 사용자 공간 입력의 유효성 검사가 필요하다. 장치 드라이버 취약점은 로컬 사용자가 악용할 수 있다. `ioctl` 인터페이스는 크고 다양하며 덜 정의되어 있어 감사가 어렵고, 제3자 구현은 취약점이 더 많을 수 있다.

Win32, 유닉스 운영 체제는 장치 접근 제어를 통해 사용자 공간 애플리케이션으로부터 장치를 보호하지만, 드라이버 개발자가 적절한 접근 제어를 적용하지 않으면 보안 문제가 발생할 수 있다. 일부 최신 운영 체제는 시스템 호출 래퍼를 사용하여 커널을 보호하지만, `ioctl` 인터페이스의 다양성 때문에 복잡성이 증가한다.

6. 1. 복잡성

`ioctl` 호출은 커널의 시스템 호출 인터페이스 복잡성을 최소화한다. 그러나 개발자가 커널 프로그래밍 인터페이스의 여러 부분을 "보관"할 수 있는 공간을 제공함으로써, `ioctl` 호출은 전체 사용자-커널 API를 복잡하게 만들 수 있다. 수백 개의 시스템 호출을 제공하는 커널은 수천 개의 `ioctl` 호출을 제공할 수 있다.

`ioctl` 호출 인터페이스는 기존 시스템 호출과 다소 다르게 보이지만, 실제로는 `ioctl` 호출과 시스템 호출 사이에 큰 차이가 없다. `ioctl` 호출은 단순히 다른 전달(디스패치) 메커니즘을 가진 시스템 호출이다. 따라서 커널 시스템 호출 인터페이스 확장에 대한 많은 반대 주장은 `ioctl` 인터페이스에도 적용될 수 있다.[1]

응용 프로그램 개발자에게 시스템 호출은 응용 프로그램 서브루틴과 다르지 않다. 즉, 인수를 받아들이고 값을 반환하는 함수 호출일 뿐이다. 핵심 라이브러리(예: `libc`)는 시스템 호출을 호출하는 데 관련된 복잡성을 숨긴다. 드라이버 인터페이스가 일반적으로 사용자 공간 라이브러리와 함께 제공되는 `ioctl`에서도 마찬가지이다. (예: 그래픽 드라이버의 직접 렌더링 인프라를 위한 Mesa)[2]

Libpcap과 libdnet은 각각 패킷 캡처 및 패킷 입/출력(I/O)을 위해 `ioctl` 인터페이스의 복잡성을 숨기도록 설계된 타사 래퍼 유닉스 라이브러리의 두 가지 예이다.[3]

6. 2. 보안

`ioctl` 호출 처리기는 링 0에 위치하므로, 사용자 공간에서 오는 입력은 주의 깊게 검증해야 한다. 장치 드라이버의 취약점은 로컬 사용자가 `ioctl` 호출에 유효하지 않은 버퍼를 전달하는 방식으로 악용될 수 있기 때문이다.

`ioctl` 인터페이스는 시스템 호출보다 크고, 다양하며, 덜 정의되어 있어 감사하기가 더 어렵다. 또한 제3자 개발자가 제공하는 `ioctl` 호출 구현은 일반적으로 덜 면밀한 조사를 받으며 더 많은 취약점을 가질 수 있다. 특히 제3자 장치 드라이버의 경우 일부 `ioctl` 호출은 완전히 문서화되지 않을 수도 있다.

Win32 및 유닉스 운영 체제는 장치에 특정 액세스 제어를 적용하여 사용자 공간 장치 이름을 애플리케이션의 접근으로부터 보호한다. 그러나 장치 드라이버 개발자가 사용자 공간에서 접근 가능한 객체에 적절한 액세스 제어를 적용하지 않으면 보안 문제가 발생할 수 있다.

일부 최신 운영 체제는 버퍼 오버플로우 익스플로잇에 감염된 애플리케이션과 같은 적대적인 사용자 공간 코드로부터 커널을 보호하기 위해 시스템 호출 래퍼를 사용한다. 시스템 호출 래퍼는 어떤 애플리케이션이 어떤 시스템 호출을 호출할 수 있는지 지정하여 역할 기반 액세스 제어를 구현한다. 그러나 `ioctl` 인터페이스는 수많은 인터페이스가 있고 각 인터페이스가 서로 다른 인수를 사용하며, 일부는 일반 프로그램에 필요할 수 있으므로 시스템 호출 래퍼를 복잡하게 만든다.

참조

[1] 웹사이트 bio(4) — block I/O ioctl tunnel pseudo-device http://bxr.su/o/shar[...] OpenBSD
[2] 웹사이트 bioctl(8) — RAID management interface http://bxr.su/o/sbin[...] OpenBSD 2005
[3] 웹사이트 sysmon(4) — system monitoring and power management interface http://mdoc.su/n/sys[...] NetBSD
[4] 서적 Perl Cookbook: Solutions & Examples for Perl Programmers https://books.google[...] O'Reilly Media, Inc. 2016-11-15
[5] 웹사이트 OpenBSD 3.6 Live http://www.onlamp.co[...] O'Reilly Media 2004-10-28
[6] 웹사이트 envsys -- Environmental Systems API http://mdoc.su/n40/e[...] 2007-12-19
[7] 간행물 Generalised Interfacing with Microprocessor System Hardware Monitors http://sensors.cnst.[...] IEEE 2007-04-17
[8] 학위논문 OpenBSD Hardware Sensors — Environmental Monitoring and Fan Control. http://cnst.su/MMath[...] UWSpace 2010-05-21
[9] 기술보고서 A Research Unix reader: annotated excerpts from the Programmer's Manual, 1971–1986 https://www.cs.dartm[...]
[10] Linux manual page ioctl(2) - Linux manual page https://man7.org/lin[...]
[11] 문서 DeviceIoControl Function (Windows) http://msdn2.microso[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com