☰

`udev`를 사용하는 것에 대한 대안이 있습니까?

tag-icon • tag-icon linux devices udev
`udev`를 사용하는 것에 대한 대안이 있습니까?

저는 udev의 위대함을 이해하고 개발자들의 노력에 감사하면서도 단순히 그에 대한 대안이 있는지 궁금했습니다.

예를 들어, 내 시스템(하드웨어 변경 없음)에서 어쨌든 거의 동일한 대부분의 장치 노드를 생성하는 시작 스크립트를 만드는 방법이 있어야 한다고 상상할 수 있습니다.

건너뛰고 싶은 이점이나 이유는 udev건너뛰기와 동일합니다 dbus. 즉, 복잡성을 줄이고 시스템을 보다 안전하게 설정하기 위한 변경 사항을 늘립니다.

답변1

최신 Linux 커널은 커널이 발견하자마자 모든 장치 노드를 동적으로 생성하는 devtmpfs파일 시스템 (고대 와 혼동하지 마십시오 devfs) 을 지원합니다. (사실 최근 udev출시된필요하다이것; udev는 더 이상 장치 노드를 생성하지 않고 심볼릭 링크만 생성한다는 것을 알 수 있습니다.)

마찬가지로 펌웨어 로딩도 커널로 이동되었으므로 udev수행되는 유일한 남은 작업은 모듈 로딩(모달리아제에 따라)과 장치 권한 및 기타 udev 규칙 적용입니다.

따라서 이론적으로 완전 단일체 커널은신병udev 없이도 괜찮습니다.

그러나 여기서 진짜 문제는 나중에 일어나는 일입니다.

  1. 상당수의 사용자 공간 프로그램은 libudev. 장치를 열거하고 추가/제거된 이벤트를 수신하는 것은 커널 인터페이스(sysfs 및 netlink)를 사용하여 직접 수행할 수 있지만 다양한 udev 규칙이 첨부한 모든 메타데이터 없이는 여전히 남게 됩니다.

  2. /dev/disk/by-*udev 규칙은 , /dev/mapper, /dev/input/by-path, /dev/snd/by-path등 의 다양한 "영구" 심볼릭 링크도 유지합니다 . 예를 들어, 두 개의 디스크가 연결되어 있는 경우 첫 번째 디스크가 항상 sda또는 이라는 보장은 없지만 sdbudev는 의 심볼릭 링크가 /dev/disk/by-uuid계속해서 올바른 디스크를 가리키도록 보장합니다.

  3. 장치 노드는 이제 커널에 의해 생성되므로 더 이상 걱정할 필요가 없지만 일부 장치 유형은 동적으로 할당된 주/부 번호를 사용하기 시작했다는 점에 유의하는 것이 여전히 중요 /dev/fuse합니다 /dev/hpet.~ 할 것이다재부팅할 때마다 숫자가 달라지므로 또는 devtmpfs(이전 시스템에서는) uevents를 수신하는 프로그램은 다음과 같습니다.필수의.

mdev물론 이러한 작업 중 상당수는 와 같은 다른 프로그램을 통해 쉽게 수행할 수 있습니다 . 내 요점은 정적 /etc/MAKEDEV스크립트가 더 이상 작동하지 않는다는 것입니다 ...

따라서 기본적으로 부팅 복잡성과 관련하여 udev는최소당신의 걱정.

답변2

udev거기 에는 다양한 대안이 있습니다 . Gentoo는 다음과 같은 것을 사용할 수 있는 것 같습니다.mdev. 또 다른 옵션은 udev의 전임자를 사용하는 것입니다 devfsd. 마지막으로 mknod.

후자의 경우 다른 옵션처럼 임시 파일 시스템이 아닌 디스크에 노드를 생성할 수 있으므로 부팅 시 모든 것을 생성할 필요가 없습니다. 물론, 새 하드웨어(예: USB 스틱)를 연결하면 장치 파일을 동적으로 생성할 수 있는 유연성이 상실됩니다. 나는 이 시대의 표준 접근 방식이 합리적으로 필요할 수 있는 모든 장치 파일을 이미 생성해 두는 것이라고 생각합니다 /dev(예: 많은 장치 파일).

물론 이러한 접근 방식 중 하나를 최신 배포판에서 작동시키는 것은 아마도 상당히 어려울 것입니다. 젠투 위키에서는 mdev데스크톱 환경에서 작업하는 데 어려움이 있다고 언급합니다(젠투 외부는 물론이고). 마지막 devfsd릴리스는 2002년이었습니다. 최신 커널에서도 작동할지 전혀 모르겠습니다. 수동으로 노드를 생성하는 것이 아마도 가장 실행 가능한 접근 방식일 것입니다. 그러나 비활성화하는 것조차 udev어려울 수 있습니다. 특히 systemd( udev는 이제 의 일부 systemd이므로 강력한 종속성을 암시합니다)를 사용하는 distos에서는 더욱 그렇습니다.

내 조언은 계속됩니다 udev;)

답변3

몇 가지 대안이 있습니다:

  • 부트스트랩의 일부로 실행되는 스크립트에 적절한 chmod, chown, 등의 명령 세트를 갖기만 하면 됩니다 .ln
  • systemd-udev시스템 프로젝트의 일부인 플러그 앤 플레이 관리자를 사용하세요 .
  • 사용젠투의eudevsystemd-udev, 이는 systemd가 이제 크게 갈라진 포크입니다 .
  • 사용데부안의vdev는 Jude Nelson이 개발한 플러그 앤 플레이 관리자로 Devuan의 일부입니다.
  • Use mdev, 다른 답변과 달리 Gentoo의 것이 아닙니다. 내장된 플러그 앤 플레이 관리자입니다.BusyBox.
  • 사용짜증나mdevDimitris Papastamos가 개발한 플러그 앤 플레이 관리자입니다.
  • 사용로랑 베르코의mdevdBusyBox와 구성이 호환되지만 mdev자체 소켓 처리를 수행하고 LISTEN 프로토콜을 이해하지 못합니다.

첫 번째를 제외하고 이들 모두에는 장치에 대한 커널 알림 이벤트에 반응하는 방법을 설명하는 규칙 세트가 필요합니다. 확실히.

/proc/sys/kernel/hotplug또한 두 개의 mdevs와 같이 를 위해 설계된 프로그램을 사용하고 netlink 소켓을 수신한 다음 해당 프로그램을 생성하여 이를 적응시키고 직렬화하는 도구도 있습니다 .

답변4

이것은 오래되었지만 헛된 검색을 하는 다른 사람들을 위해 여기에 내 솔루션을 캡처하고 싶습니다.
udev를 피하는 것은 쉽지 않습니다. DEVTMPFS를 구성에서 제외해도 커널이 /dev에 RAM 디스크를 마운트하고 채우는 것이 중단되지 않습니다. 불행하게도 필요한 /dev/shm 및 /dev/pts 마운트 지점을 생성하지 않습니다. 필요한 것은 부팅 인수에 devtmpfs.mount=0을 추가하는 것입니다.

관련 정보