맨위로가기

Udev

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

1. 개요

udev는 리눅스 시스템에서 장치 관리를 담당하는 데몬이다. 리눅스 커널 2.5에서 처음 도입되었으며, 커널이 새로운 장치를 인식하거나 제거할 때 발생하는 uevent를 수신하여 장치 노드를 동적으로 생성하고 관리한다. 2012년 systemd에 통합되었으며, eudev와 같은 포크도 존재한다. udev는 libudev 라이브러리, udevd 데몬, udevadm 명령줄 유틸리티로 구성되며, 영구적인 장치 이름 지원 및 사용자 공간에서 장치 설정을 수행하는 기능을 제공한다.

더 읽어볼만한 페이지

  • 컴퓨터 설정 - 마법사 (소프트웨어)
    마법사는 소프트웨어에서 사용자를 안내하고 작업을 쉽게 수행하도록 돕는 인터페이스 요소이며, 1991년 마이크로소프트 퍼블리셔에 도입된 후 다양한 운영체제 및 프로그램에서 사용되었으나, 복잡성과 맥락 제거에 대한 비판과 함께 용어 사용은 점차 사라지는 추세이다.
  • 컴퓨터 설정 - Zeroconf
    제로컨피그(Zeroconf)는 네트워크 장치가 수동 설정 없이 자동으로 네트워크에 연결하고 서비스를 검색할 수 있게 해주는 기술 모음으로, 주소 할당, 이름 확인, 서비스 검색 등을 포함하며, Apple의 Bonjour, Linux의 Avahi, Windows의 LLMNR 등이 주요 구현이다.
  • 리눅스 커널 인터페이스 - 장치 파일
    유닉스 및 유닉스 계열 운영 체제에서 하드웨어 장치 접근을 위해 사용되는 특수 파일 시스템 객체인 장치 파일은 문자 장치와 블록 장치로 나뉘며 주 번호와 부 번호로 식별되고, 물리 장치 외에 가상 장치도 존재하며 다른 운영 체제에서도 유사한 개념으로 특정 포트와 장치에 접근하는 데 사용된다.
  • 리눅스 커널 인터페이스 - 리눅스 기본 규격
    리눅스 기본 규격(LSB)은 리눅스 배포판 간 호환성 증진을 목표로 하는 표준으로, 다양한 발전을 거쳤으나 비판과 제한적인 적용 사례가 있다.
  • 유닉스 파일 시스템 관련 소프트웨어 - Filesystem in Userspace
    Filesystem in Userspace (FUSE)는 사용자 공간에서 파일 시스템을 구현하는 인터페이스로, 커널 수정 없이 파일 시스템 개발을 가능하게 하며, libfuse 라이브러리를 통해 다양한 운영체제 및 프로그래밍 언어를 지원한다.
  • 유닉스 파일 시스템 관련 소프트웨어 - Chmod
    chmod는 파일 및 디렉터리의 접근 권한을 변경하는 유닉스 명령어이며, 문자열 또는 숫자 모드를 사용하여 권한을 설정하고 재귀적으로 하위 디렉터리에도 적용할 수 있다.
Udev - [IT 관련 정보]에 관한 문서
일반 정보
명칭udev
종류장치 노드
개발 언어C
운영 체제리눅스
라이선스GPLv2
웹사이트공식 웹사이트
개발
개발자Greg Kroah-Hartman, Kay Sievers
최초 릴리스2003년 11월
기타
저장소/dev

2. 역사

udev는 리눅스 2.5에서 처음 도입되었다. 이후 리눅스 커널 버전 2.6.13에서 uevent 인터페이스가 업데이트되는 등 변화를 거쳤으며, 2012년 4월에는 systemd 프로젝트의 소스 트리에 병합되었다.[4][9][10] 이러한 변화 과정에서 커널 버전 호환성 문제나 systemd 통합을 둘러싼 논의들이 있었다.

2. 1. 커널 버전 호환성 문제

udev는 리눅스 2.5에서 처음 도입되었다.

리눅스 커널 버전 2.6.13에서는 uevent 인터페이스의 새로운 버전이 도입되거나 업데이트되었다. 이로 인해 새로운 버전의 udev를 사용하는 시스템은, udev 기능을 비활성화하고 장치 접근을 위해 예전 방식의 정적 `/dev` 디렉터리를 사용하지 않는 한, 커널 버전 2.6.13 미만에서는 부팅되지 않는다. 즉, 구버전 커널을 사용하려면 udev를 끄고 예전 방식의 정적 `/dev` 디렉터리를 이용해야 한다.

2. 2. systemd와의 통합

2012년 4월, udev의 코드베이스는 systemd 소스 트리에 병합되었고, systemd 버전 183부터 udev를 포함하게 되었다.[4][9][10]

같은 해 10월, 리누스 토르발스는 Kay Sievers가 펌웨어 로딩과 관련하여 udev를 유지보수하고 버그를 수정하는 방식에 대해 비판적인 입장을 표명했다.[11] 그는 커널에서 펌웨어 로딩을 처리하는 것이 더 안정적인 이유가 사용자 공간에서의 처리 능력 부족 때문이 아니라, udev 유지보수의 질적 하락 때문이라고 지적하며 다음과 같이 말했다.

:그래, 커널에서 하는 것이 "더 견고"하다. 하지만 속임수를 쓰지 말고 거짓말도 그만두세요. 더 견고한 이유는 우리가 신경 쓰는 유지보수 담당자가 있고, 회귀가 우리가 대충 넘어갈 수 있는 것이 아니라는 것을 알고 있기 때문입니다. 무언가 깨지고, 그 깨짐에 대한 적절한 수정 사항이 무엇인지 모르면, 우리는 깨진 것을 '되돌립니다'. 그래서, 예, 커널에서 하는 것이 분명히 더 좋습니다. 펌웨어 로딩을 사용자 공간에서 할 수 없기 때문이 아니라, Greg가 포기한 이후 udev 유지보수가 내리막길을 걸었기 때문입니다.

한편, 2012년에 젠투 리눅스 프로젝트는 systemd 아키텍처에 대한 의존성을 피하고자 systemd의 udev 코드베이스를 포크하여 ''eudev''를 만들었다. eudev는 systemd 없이도 udev 기능을 사용할 수 있도록 하는 것을 목표로 하며, 특정 리눅스 배포판이나 init 시스템에 구애받지 않는 독립성을 지향한다.[12] 젠투 프로젝트는 eudev에 대해 다음과 같이 설명했다.[13]

:eudev는 OpenRC 및 Upstart, 이전 커널, 다양한 툴체인 및 사용자와 다양한 배포판에 필요한 기타 모든 소프트웨어와의 더 나은 호환성을 얻기 위한 목표를 가진 systemd-udev의 포크입니다.

2014년 5월 29일, 펌웨어 로딩은 커널의 책임이라는 결정에 따라 systemd에서 udev를 통한 펌웨어 로딩 지원이 제거되었다.[14] 그러나 이틀 뒤, Lennart Poettering은 kdbus가 udev에서 사용되기 시작할 때까지 해당 변경 사항 적용을 연기하자고 제안했다. 당시 계획은 udev의 기본 메시징 시스템을 kdbus로 전환하고, 기존의 사용자 공간 간 netlink 기반 전송 방식을 제거하는 것이었다.[15]

3. 설계 및 작동 방식

리눅스 시스템에서 udev는 `/dev` 디렉터리의 장치 노드를 관리하는 핵심 구성 요소이다. 전통적인 유닉스 시스템이 시스템에 존재할 수 있는 모든 장치 노드를 정적으로 미리 만들어두는 방식과 달리, udev는 시스템에 실제로 연결된 하드웨어 장치에 해당하는 노드만 동적으로 생성하고 제거한다.[20][3][16] 이는 과거 리눅스에서 사용되었던 devfs와 유사한 기능이지만, udev는 사용자 공간에서 실행되어 더 유연하고 안정적인 장치 관리를 가능하게 하며, 장치가 연결되는 순서에 상관없이 항상 동일한 이름으로 장치를 식별할 수 있는 영속적인 장치 이름 기능 등 중요한 개선점을 제공한다.[20][3][16]

핫플러그 기능을 지원하는 주변 장치를 효과적으로 관리하기 위해, 커널은 하드웨어 감지 후 기본적인 정보(uevent)를 사용자 공간의 udev 데몬(`udevd`)에게 전달한다.[1][17] `udevd`는 이 정보를 바탕으로 시스템에 정의된 규칙(rules)에 따라 장치 노드를 생성하고, 필요한 권한 설정이나 추가 스크립트를 실행하는 등 복잡한 작업을 처리한다. 이러한 사용자 공간에서의 처리는 시스템의 보안과 안정성을 높이는 데 기여한다.[1] 초기 버전에서는 핫플러그 시스템을 이용하기도 했으나, 현재는 주로 넷링크 소켓을 통해 커널과 통신한다.

udev는 크게 세 가지 구성 요소로 나뉜다:


  • '''libudev''': 응용 프로그램이 장치 정보에 접근할 수 있도록 하는 라이브러리. systemd에 통합되었다.[4]
  • '''udevd''': 커널로부터 uevent를 수신하고 규칙에 따라 장치 노드를 관리하는 핵심 데몬.
  • '''udevadm''': udev 시스템을 관리하고 진단하는 명령 줄 유틸리티.


과거에는 udev가 HAL(Hardware Abstraction Layer)과 연동하여 데스크톱 환경에 장치 정보를 전달하는 역할을 했으나,[5][17] 현재는 HAL의 기능이 udev 자체나 udisks, upower, NetworkManager 등 전문화된 데몬으로 이전되었다.[6][7][8][18][19] 현대 시스템에서 udev는 커널과 이들 상위 데몬 사이에서 하드웨어 이벤트를 중계하고 기본적인 장치 노드 관리를 수행하며, 애플리케이션은 D-Bus를 통해 상위 데몬과 통신하여 장치를 활용한다.[8]

3. 1. 규칙(Rules) 시스템

Udev는 리눅스 시스템에서 데몬으로 실행되며, 커널이 새로운 장치가 초기화되거나 시스템에서 장치가 제거될 때 내보내는 uevent를 netlink 소켓을 통해 수신하는 일반적인 장치 관리자이다. udev 시스템의 핵심은 규칙(rules) 시스템이다.[17]

시스템 관리자는 udev 규칙 파일들을 통해 장치 이벤트를 처리하는 방식을 정의할 수 있다. 이 규칙들은 커널이 보낸 이벤트 정보(uevent)와 시스템에 연결된 장치의 속성을 기반으로 작동한다. 규칙 파일은 특정 조건에 맞는 장치를 식별하고, 해당 장치에 대해 수행할 작업을 명시한다. 매칭 조건으로는 커널 하위 시스템 이름, 커널이 할당한 장치 이름, 장치의 물리적 위치(예: 특정 USB 포트), 장치의 고유한 속성(예: 시리얼 번호) 등이 사용될 수 있다.[17]

일치하는 규칙이 발견되면, udev는 다음과 같은 작업을 수행할 수 있다.

  • 장치 노드 생성 및 명명: `/dev` 디렉터리에 해당 장치를 나타내는 장치 노드를 생성한다. 이때 규칙을 통해 장치 노드의 이름을 지정할 수 있다. 특히, udev는 장치가 시스템에 연결되는 순서와 관계없이 항상 동일한 이름을 갖도록 영구적인 장치 이름을 부여하는 기능을 지원한다. 예를 들어, 저장 장치는 고유한 파일 시스템 ID, 디스크 레이블, 또는 하드웨어의 물리적 위치 정보를 기반으로 일관된 이름(예: `/dev/disk/by-uuid/` 또는 `/dev/disk/by-id/`)을 부여받을 수 있다.[3][16] 이는 시스템 재부팅이나 장치 연결 순서 변경에도 불구하고 안정적으로 장치를 참조할 수 있게 해준다.
  • 프로그램 실행: 장치 설정 및 구성을 위해 미리 정의된 외부 프로그램이나 스크립트를 실행할 수 있다. 예를 들어, 특정 펌웨어를 로드하거나 네트워크 인터페이스 설정을 초기화하는 등의 작업을 자동화할 수 있다.[17] 규칙은 외부 프로그램에 정보를 요청하여 장치 이름을 결정하거나 추가적인 설정을 수행하는 데 활용할 수도 있다.


과거에는 udev가 감지한 하드웨어 이벤트를 HAL(Hardware Abstraction Layer)이라는 별도의 데몬으로 전달하여 처리하는 방식이 일반적이었다. HAL은 D-Bus를 통해 데스크톱 환경(GNOME, KDE 등)에 알림을 보내, 사용자가 새로운 USB 플래시 드라이브를 연결했을 때 자동으로 파일 관리자를 실행하는 등의 사용자 친화적인 기능을 구현했다.[5][17]

그러나 2011년경부터 대부분의 리눅스 배포판에서는 HAL 사용을 중단하고, 그 기능을 udev 자체나 다른 특화된 데몬들로 이전했다.[6][7][18][19] 예를 들어, 저장 장치 관리는 `udisks` 데몬이, 전원 관리는 `upower` 데몬이 담당하게 되었으며, 이 데몬들은 udev로부터 장치 정보를 받아 필요한 작업을 수행하고 D-Bus를 통해 애플리케이션과 통신한다. NetworkManager 역시 udev와 연동하여 네트워크 장치를 관리한다.[8] 이로 인해 udev는 하드웨어 이벤트를 감지하고 기본적인 장치 노드 관리 및 규칙 처리를 담당하며, 더 복잡하고 높은 수준의 장치 관리는 `udisks`, `upower`, `NetworkManager` 같은 전문화된 데몬들이 처리하는 구조가 되었다.

이러한 현대적인 구조는 다음과 같은 정보 흐름을 가진다:

`커널 → udev → Network Manager ↔ D-Bus ↔ Firefox` (예시)[8]

udev 규칙 시스템은 사용자 공간에서 실행되므로, 커널 코드 변경 없이도 유연하게 장치 관리 정책을 수정하고 확장할 수 있다는 장점이 있다. 이는 과거 devfs가 커널 공간에서 작동했던 것과 대조되는 특징이다.[3][16]

3. 2. 영속적인 장치 이름

전통적인 유닉스 시스템에서는 `/dev` 디렉터리에 시스템에 존재할 수 있는 모든 장치에 대한 장치 노드 파일을 미리 만들어 두는 정적인 방식을 사용했다. 이와 달리 리눅스의 udev 장치 관리자는 시스템에 실제로 존재하는 장치들의 노드만을 동적으로 제공한다.[20][3][16] 과거 devfs가 비슷한 동적 관리 기능을 제공했지만, udev는 몇 가지 중요한 개선점을 가지고 있다.[20][3][16]

udev의 주요 특징 중 하나는 영속적인 장치 이름을 지원한다는 점이다.[20][3][16] 이는 장치가 컴퓨터에 연결되는 순서나 시점에 관계없이 항상 동일한 이름으로 장치를 식별할 수 있게 해준다. 예를 들어, USB 저장 장치를 어떤 포트에 연결하든, 또는 시스템 부팅 시 어떤 순서로 인식되든 상관없이 미리 정해진 고유한 이름으로 접근할 수 있다. 기본 udev 설정은 저장 장치에 대해 이러한 영구적인 이름을 제공하며, 이때 다음과 같은 정보를 활용한다:

  • 고유한 파일 시스템 ID
  • 디스크 자체의 이름 (레이블)
  • 하드웨어가 장착된 물리적 위치 (예: ATA 인터페이스의 마스터/슬레이브 구분 등)[20][3][16]


이러한 영속적인 이름 지정 방식은 시스템 관리의 안정성과 예측 가능성을 크게 높인다. 또한, udev는 devfs와 달리 커널 공간이 아닌 사용자 공간에서 실행된다는 중요한 차이점이 있다.[20][3][16] 이 덕분에 udev는 장치 이름을 결정하는 정책을 커널 외부에서 관리할 수 있으며, 장치 노드를 생성하기 전에 다양한 프로그램을 실행하여 장치의 속성 정보를 바탕으로 더욱 유연하고 복잡한 이름 규칙을 적용할 수 있다. 이 과정은 사용자 공간에서 실행되므로 시스템 전체에 영향을 주지 않고 중단하거나 우선순위를 낮춰 실행하는 것이 가능하다.[20][3]

3. 3. HAL과의 연동 (과거)

과거 리눅스 시스템에서 udev는 일반적으로 장치 관련 추가 작업을 수행하기 위해 소켓을 통해 HAL로 이벤트를 전송하는 방식을 사용했다. 예를 들어, HAL은 새로운 하드웨어가 연결되었음을 D-Bus IPC 시스템을 통해 관련된 모든 프로세스에 브로드캐스트 메시지를 발행하여 시스템에서 실행 중인 다른 소프트웨어에 알렸다. 이러한 방식으로 GNOME이나 KDE와 같은 데스크톱 환경에서는 새로 연결된 USB 메모리나 SD 카드의 파일 시스템을 탐색하기 위해 파일 브라우저를 자동으로 시작할 수 있었다.[5][17]

그러나 2011년 중반까지 KDE, GNOME[6][18], Xfce[7][19] 데스크톱 환경을 포함한 대부분의 리눅스 배포판에서는 HAL 사용을 중단했다. 이전에 HAL에 포함되었던 기능은 udev 자체에 통합되거나 udisks 및 upower와 같은 별도의 소프트웨어로 분리되었다. HAL을 대체하기 위해 새로운 데몬인 DeviceKit이 계획되기도 했으나, 2009년 3월에 해당 기능 코드를 udev-extras라는 패키지로 udev에 추가하는 방향으로 결정되면서 DeviceKit은 더 이상 사용되지 않게 되었다. 현재 HAL은 레거시 코드를 제외하고는 거의 사용되지 않는다.

4. 구성 요소

리눅스의 udev 장치 관리자는 시스템에 실제로 존재하는 장치들의 장치 노드만 동적으로 제공하며, 이는 `/dev` 디렉터리에 정적인 파일들을 모아두는 전통적인 유닉스 시스템과는 다른 방식이다. 과거 devfs가 비슷한 기능을 제공했지만, udev는 몇 가지 개선점을 가지고 있다.[20] 예를 들어, udev는 장치가 시스템에 연결된 순서에 의존하지 않는 영속적인 장치 명명 기능을 지원하며, 커널 공간이 아닌 사용자 공간에서 실행되어 명명 정책을 커널 외부에서 관리하고 임의의 프로그램을 통해 장치 이름을 결정할 수 있게 한다.

udev 시스템은 크게 세 가지 주요 구성 요소로 나눌 수 있다.


  • libudev: 장치 정보에 접근하기 위한 라이브러리이다.
  • udevd: 사용자 공간에서 실행되며 가상 `/dev` 디렉토리를 관리하는 데몬이다.
  • udevadm: 시스템 관리자가 udev를 제어하고 진단 정보를 확인하기 위한 명령 줄 유틸리티이다.


시스템은 넷링크 소켓을 통해 커널로부터 장치 관련 이벤트(uevent)를 수신한다. 초기 버전의 udev는 이러한 목적으로 핫플러그를 사용했으며, `/etc/hotplug.d/default`에 자기 자신을 위한 링크를 추가하는 방식으로 작동했다.

4. 1. libudev

libudev는 장치 정보에 접근할 수 있게 해주는 라이브러리이다. 이는 systemd 소프트웨어 번들에 통합되었다.[4]

4. 2. udevd

udevd는 가상 `/dev` 디렉토리를 관리하는 사용자 공간 데몬이다.[4] 전통적인 유닉스 시스템에서는 `/dev` 디렉토리에 시스템에 존재할 수 있는 모든 장치를 위한 장치 노드 파일들이 정적으로 미리 만들어져 있었지만, udev는 시스템에 실제로 연결되어 존재하는 장치들에 대한 노드만을 동적으로 생성하고 제거한다. 이는 과거에 사용되었던 devfs와 유사한 기능을 제공하지만, udev는 몇 가지 중요한 개선점을 가지고 있다.

udevd는 리눅스 커널이 핫플러그 기능을 통해 새로운 장치가 시스템에 연결되거나 기존 장치가 제거될 때 발생하는 이벤트(이를 uevent라고 한다)를 netlink 소켓을 통해 수신한다. 커널 내부에 포함된 장치 드라이버는 하드웨어의 변화를 감지하는 등의 저수준 작업을 수행하고, 관련된 이벤트 정보를 사용자 공간에서 실행 중인 udevd에게 전달한다.[1]

udevd는 커널로부터 이벤트를 받으면, 미리 정의된 규칙(rules)에 따라 어떤 작업을 수행할지 결정한다. 이 규칙들은 보통 `/etc/udev/rules.d/` 디렉토리에 텍스트 파일 형태로 저장되어 있으며, 관리자가 필요에 따라 수정하거나 추가할 수 있다. 규칙들은 커널이 보고한 장치의 속성들, 예를 들어 장치가 속한 하위 시스템(예: `usb`, `block`), 커널이 내부적으로 사용하는 장치 이름(예: `sda`, `ttyS0`), 장치가 연결된 물리적 위치(예: 특정 USB 포트), 또는 장치의 고유 식별자(예: 하드 디스크의 시리얼 번호) 등을 조건으로 사용하여 특정 장치를 식별한다.

규칙이 특정 이벤트와 일치하면, udevd는 해당 규칙에 명시된 동작을 수행한다. 가능한 동작은 다음과 같다.

  • `/dev` 디렉토리에 장치 노드 파일 생성 및 이름 지정. 예를 들어, 첫 번째 SCSI 디스크의 첫 번째 파티션에 대해 `/dev/sda1`과 같은 노드를 생성할 수 있다. 또한, udev는 장치가 연결된 순서나 포트에 관계없이 항상 동일한 이름을 갖도록 영속적인 장치 이름을 부여하는 기능을 지원한다. 예를 들어, 디스크의 고유 ID나 레이블을 사용하여 `/dev/disk/by-id/` 또는 `/dev/disk/by-label/`과 같은 경로에 심볼릭 링크를 생성할 수 있다.
  • 생성된 장치 노드 파일의 접근 권한 및 소유권 설정.
  • 장치 초기화나 설정을 위해 필요한 추가적인 스크립트나 외부 프로그램 실행.
  • 시스템의 다른 부분, 특히 고수준의 장치 관리를 담당하는 데몬들에게 이벤트 발생을 알림. 예를 들어, 새로운 저장 장치가 연결되면 udisks 데몬에게 알려 파일 시스템 마운트 등의 후속 작업을 가능하게 하고, 네트워크 인터페이스 상태가 변경되면 NetworkManager 데몬에게 알려 네트워크 연결 설정을 관리하도록 한다.


예를 들어, 사용자가 USB 메모리 스틱을 컴퓨터에 꽂으면, 커널의 USB 드라이버가 이를 감지하고 udevd에게 uevent를 보낸다. udevd는 규칙을 확인하여 이 장치가 저장 장치임을 인식하고, `/dev/sdb` (예시)와 같은 장치 노드를 생성하며, 필요하다면 파일 시스템 레이블에 기반한 영속적인 이름 링크도 만든다. 동시에 udevd는 udisks 데몬에게 새로운 저장 장치가 사용 가능함을 알린다. 그러면 udisks는 D-Bus 메시지를 통해 파일 탐색기와 같은 데스크톱 애플리케이션에게 이를 통지하고, 사용자는 파일 탐색기를 통해 해당 USB 드라이브에 접근할 수 있게 된다.

udevd가 사용자 공간에서 실행된다는 점은 커널 공간에서 작동했던 devfs에 비해 중요한 이점을 제공한다.[3] 사용자 공간에서 실행되기 때문에, 장치 이름 지정 정책을 커널 코드와 분리하여 더 유연하게 관리할 수 있다. 또한, 장치 노드를 생성하기 전에 외부 프로그램을 실행하여 장치로부터 추가 정보를 얻거나 복잡한 조건에 따라 이름을 결정하는 것이 가능하다. 이러한 작업들이 커널 외부의 일반 프로세스로 처리되므로, 시스템 전체의 안정성에 영향을 덜 미치고, 필요하다면 작업을 중단하거나 낮은 우선순위로 실행할 수도 있다.

과거 리눅스 시스템에서는 HAL(Hardware Abstraction Layer)이라는 별도의 데몬이 udev와 함께 사용되어 하드웨어 이벤트를 보다 추상화된 형태로 애플리케이션에 전달하는 역할을 담당했다.[5] HAL은 D-Bus를 통해 데스크톱 환경(GNOME, KDE)에 새로운 하드웨어 연결 사실을 알리고, 데스크톱 환경은 이를 바탕으로 사용자에게 알림을 표시하거나 관련 프로그램을 실행했다. 하지만 2011년경부터 HAL은 점차 사용되지 않게 되었고[6][7], 그 기능들은 udev 자체나 udisks, upower(전원 관리 데몬) 등 다른 특화된 데몬들로 통합되거나 대체되었다.[8]

전체적으로 udev 시스템은 세 가지 주요 구성 요소로 이루어져 있다. 첫째는 장치 정보에 접근하기 위한 라이브러리인 `libudev`이고, 둘째는 커널로부터 이벤트를 받아 처리하고 `/dev` 디렉토리를 관리하는 핵심 데몬인 `udevd`이며, 셋째는 시스템 관리자가 udev의 상태를 확인하고 제어하는 데 사용하는 명령 줄 유틸리티인 `udevadm`이다. 이 중 udevd는 커널과 사용자 공간의 다른 서비스 및 애플리케이션 사이에서 장치 관련 이벤트를 중계하고 관리하는 중추적인 역할을 수행한다.

4. 3. udevadm

udev는 전체적으로 세 부분으로 나뉜다.[4]

  • 라이브러리 ''libudev'': 장치 정보에 접근할 수 있게 해준다. systemd 소프트웨어 번들에 통합되었다.[4]
  • 데몬 ''udevd'': 사용자 공간에서 가상 /dev 디렉터리를 관리한다.
  • 관리용 명령어 ''udevadm'': 장치 관리 및 진단 정보를 확인하는 데 사용된다.

4. 4. 펌웨어 로딩 문제

2012년 10월, 리누스 토르발스는 Kay Sievers의 펌웨어 로딩 관련 udev 유지보수 및 버그 수정 방식에 대해 비판했다.[11] 그는 "그래, 커널에서 하는 것이 '더 견고'하다. 하지만 속임수를 쓰지 말고 거짓말도 그만두세요. 더 견고한 이유는 우리가 신경 쓰는 유지보수 담당자가 있고, 회귀가 우리가 대충 넘어갈 수 있는 것이 아니라는 것을 알고 있기 때문입니다. 무언가 깨지고, 그 깨짐에 대한 적절한 수정 사항이 무엇인지 모르면, 우리는 깨진 것을 '되돌립니다'. 그래서, 예, 커널에서 하는 것이 분명히 더 좋습니다. 펌웨어 로딩을 사용자 공간에서 할 수 없기 때문이 아니라, Greg가 포기한 이후 udev 유지보수가 내리막길을 걸었기 때문입니다."라고 언급하며, 커널에서 펌웨어 로딩을 하는 것이 더 안정적이라고 주장했다. 이는 커널 유지보수 담당자들이 회귀 문제에 더 신경 쓰고 문제가 발생했을 때 변경 사항을 되돌리는 등 책임감 있는 관리를 하기 때문이라고 설명했다. 또한 Greg Kroah-Hartman이 관여하지 않게 된 이후 udev 유지보수가 부실해졌다고 지적했다.

같은 해 2012년, 젠투 리눅스 프로젝트는 systemd 아키텍처에 대한 종속성을 피하기 위해 systemd의 udev 코드베이스를 포크하여 ''eudev''를 만들었다. 이 프로젝트의 목표는 eudev를 특정 리눅스 배포판이나 init 시스템과 독립적으로 유지하는 것이었다.[12] 젠투 프로젝트는 eudev를 "OpenRC 및 Upstart, 이전 커널, 다양한 툴체인 및 사용자와 다양한 배포판에 필요한 기타 모든 소프트웨어와의 더 나은 호환성을 얻기 위한 목표를 가진 systemd-udev의 포크"라고 설명했다.[13]

2014년 5월 29일, 펌웨어를 로드하는 작업은 커널의 임무로 결정됨에 따라 udev를 통한 펌웨어 로딩 지원이 systemd에서 제거되었다.[14] 이틀 후인 5월 31일, Lennart Poettering은 이 패치의 적용을 kdbus가 udev에서 사용되기 시작할 때까지 연기할 것을 제안했다. 당시 계획은 udev의 기본 메시징 시스템을 kdbus로 전환하고, 사용자 공간 간 통신에 사용되던 netlink 기반 전송 방식을 제거하는 것이었다.[15]

4. 5. 복잡성 증가

장치 드라이버는 리눅스 커널의 일부로 저수준 하드웨어 기능을 처리하며, 여기서 발생하는 이벤트는 사용자 공간의 `udevd` 데몬으로 전달된다. `udevd`는 이 이벤트를 받아 구성 파일에 따라 처리 방향을 결정한다. 예를 들어, 새로운 저장 장치가 연결되면 `udisksd` 데몬에 알려 파일 시스템 마운트를 준비하게 하고, 네트워크 케이블이 연결되면 `NetworkManager` 데몬에 알려 네트워크 설정을 진행하게 한다.

하지만 이러한 구조는 애플리케이션 개발자에게 복잡성을 증가시키는 요인이 되었다. 개발자들은 하드웨어 지원 로직을 직접 구현해야 했으며, 특정 하드웨어 기능을 사용하기 위해 별도의 권한 상승 프로그램이 필요했다. 이는 일반적인 유닉스 권한 모델로는 관리하기 어려운 경우가 많았고(예: 특정 사용자 환경에서만 무선 네트워크 연결 허용), 개발자들이 setuid 바이너리나 별도 서비스 데몬을 사용하게 만들어 잠재적인 보안 취약점을 만들기도 했다.[2]

이러한 문제를 해결하기 위해 한때 HAL이 사용되었다. 과거 리눅스 시스템에서는 udev가 감지한 하드웨어 이벤트를 HAL로 전달하면, HAL이 D-Bus IPC를 통해 시스템 내 다른 프로세스들에게 알리는 방식으로 동작했다. 이를 통해 GNOME이나 KDE 플라스마 3 같은 데스크톱 환경은 새로운 USB 플래시 드라이브나 SD 카드가 연결되었을 때 자동으로 파일 브라우저를 실행하는 등의 기능을 구현할 수 있었다.[5]

그러나 2011년 중반을 기점으로 HAL은 GNOME[6], Xfce[7] 등 주요 리눅스 환경에서 점차 사용되지 않게 되었다. 기존에 HAL이 담당하던 기능들은 udev 자체로 통합되거나, 다음과 같은 특화된 데몬들로 분리되어 발전했다.

  • `udisks` (구 DeviceKit-disks): 저장 장치 관리를 위한 고수준 인터페이스 제공 (D-Bus 통해 접근).
  • upower (구 DeviceKit-power): 전원 관리를 위한 고수준 인터페이스 제공 (D-Bus 통해 접근).
  • NetworkManager: 네트워크 설정을 위한 고수준 인터페이스 제공 (D-Bus 통해 접근).[8]


결과적으로 현대 리눅스 시스템의 장치 관리 아키텍처는 커널이 udev에게 이벤트를 전달하고, udev는 이를 `udisks`, `upower`, `NetworkManager` 등 각각의 전문화된 데몬에게 넘겨주며, 애플리케이션은 D-Bus를 통해 이 데몬들과 상호작용하는 방식으로 변화했다. 예를 들어, 웹 브라우저가 네트워크 상태를 확인하는 과정은 '커널 → udev → NetworkManager ↔ D-Bus ↔ 웹 브라우저'와 같은 흐름으로 이루어진다. HAL은 현재 레거시 시스템 지원 외에는 거의 사용되지 않으며, 우분투 10.04 버전부터는 기본적으로 포함되지 않았다. HAL을 대체하려던 DeviceKit 프로젝트 역시 2009년 udev-extras 패키지로 기능이 흡수되면서 중단되었다.

참조

[1] 웹사이트 Are top Linux developers losing the will to code? https://web.archive.[...] 2024-06-02
[2] 간행물 Making Hardware Just Work http://ometer.com/ha[...] 2003-07-10
[3] 웹사이트 udev and devfs - The final word http://kernel.org/pu[...] 2008-01-24
[4] 웹사이트 systemd/systemd https://github.com/s[...] 2016-08-21
[5] 웹사이트 Dynamic Device Management in Udev Linux Magazine 2008-07-14
[6] 웹사이트 HALRemoval http://wiki.debian.o[...] 2011-09-13
[7] 웹사이트 Thunar-volman and the deprecation of HAL in Xfce https://web.archive.[...] 2017-12-25
[8] 웹사이트 Relationship between udev, hal, Dbus and DeviceKit? http://lists.freedes[...] 2010-04-25
[9] 간행물 The future of the udev source tree http://article.gmane[...] 2013-05-22
[10] 간행물 Commit importing udev into systemd http://cgit.freedesk[...] 2013-05-22
[11] 간행물 Re: udev breakages https://lkml.org/lkm[...] 2014-10-28
[12] 웹사이트 gentoo/eudev – README.md https://github.com/g[...] 2017-12-25
[13] 웹사이트 Gentoo Linux Projects – Gentoo eudev project https://web.archive.[...] 2017-12-25
[14] 웹사이트 '[systemd-devel] [PATCH] Drop the udev firmware loader' http://lists.freedes[...] 2014-05-29
[15] 웹사이트 '[systemd-devel] [PATCH] Drop the udev firmware loader' http://lists.freedes[...] 2014-05-31
[16] 웹사이트 udev and devfs - The final word http://kernel.org/pu[...] 2008-01-24
[17] 웹사이트 Dynamic Device Management in Udev http://w3.linux-maga[...] Linux Magazine 2008-07-14
[18] 웹사이트 HALRemoval http://wiki.debian.o[...] wiki.debian.org 2011-09-13
[19] 웹사이트 Thunar-volman and the deprecation of HAL in Xfce http://gezeiten.org/[...] 2011-09-13
[20] 웹인용 udev and devfs - The final word http://kernel.org/pu[...] 2008-01-24


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

문의하기 : help@durumis.com