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

나는 udev의 위대함을 이해하고 개발자의 노력에 감사하는 반면, 대안이 있는지 궁금합니다.

예를 들어, 시스템에서 하드웨어를 변경하지 않고도 대부분의 장치 노드를 생성하는 시작 스크립트를 만드는 방법이 있다고 생각할 수도 있습니다.

건너 뛰고 싶은 이점 또는 이유 udev는 건너 뛰는 것과 동일합니다 dbus. 즉, 복잡성을 줄이고 시스템을 안전하게 설정하기 위해 변경 사항을 늘리면됩니다.

거기에 다양한 대안 udev이 있습니다. 겉보기 Gentoo는라는 것을 사용할 수 있습니다 mdev. 또 다른 옵션은 udev선행 작업 을 사용하는 것 devfsd입니다. 마지막으로 언제든지 필요한 모든 장치 파일을 만들 수 있습니다 mknod.

후자는 다른 옵션과 마찬가지로 임시 파일 시스템이 아닌 디스크에서 노드를 작성할 수 있으므로 부트시 모든 것을 작성할 필요가 없습니다. 물론 새로운 하드웨어가 연결되면 (예 : USB 스틱) 동적으로 생성 된 장치 파일의 유연성을 잃게됩니다. 이 시대의 표준 접근 방식은 이미 필요할 수있는 모든 장치 파일 /dev(예 : 많은 장치 파일)을 갖는 것입니다.

물론 현대의 배포판에서 이러한 접근 방식을 사용하기가 어려울 수도 있습니다. 젠투 위키는 mdev데스크탑 환경에서 작업하는 데 어려움이 있다고 언급 합니다 (젠투 외부는 제외). 마지막 devfsd릴리스는 2002였습니다. 최신 커널에서도 전혀 작동하지 않을지 모르겠습니다. 수동 노드를 만들기 아마도 가장 가능한 방법이지만, 심지어 사용하지 udev특히 사용 distos에 도전을 할 수있는 것은 systemd( udev지금 일부 systemd강한 의존성을 제안한다).

내 충고는 udev;)에 충실합니다 .

최신 Linux 커널은 devtmpfs파일 시스템을 지원합니다 ^{(고대와 혼동하지 마십시오 devfs).} 커널은 파일 시스템을 발견하자마자 모든 장치 노드를 동적으로 생성합니다. (사실, 최신 udev릴리스 에는 이것이 필요 합니다. udev는 더 이상 장치 노드를 만들지 않고 심볼릭 링크 만 만듭니다.)

마찬가지로 펌웨어 로딩도 커널로 옮겨 udev졌으므로 모듈로드 (모 달리아 제에 따라) 및 장치 권한 및 기타 udev 규칙 적용 만 수행됩니다.

따라서 이론적으로 완전 모 놀리 식 커널은 udev없이 정상적으로 부팅 해야합니다 .

그러나 여기서 실제 문제는 나중에 발생하는 문제입니다.

1. 상당수의 사용자 공간 프로그램은를 통해 액세스 가능한 장치 데이터베이스를 유지 관리하는 udev에 의존합니다 libudev. 커널 인터페이스 (sysfs 및 netlink)를 사용하여 장치를 열거하고 추가 / 제거 된 이벤트 수신을 직접 수행 할 수는 있지만 다양한 udev 규칙에 첨부 된 모든 메타 데이터 없이도 여전히 남아 있습니다.

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

3. 장치 노드가 이제 커널에 의해 생성되므로하지 우려 더 이상 동안, 당신이이 순간에도, 여전히 몇 가지 장치 유형을 동적으로 할당 메이저 / 마이너 번호를 사용하여 시작하는 것이 중요하다 /dev/fuse10228로하고 /dev/hpet오늘 10229, 그들은 것이다 재부팅 할 때마다 다른 번호를 가지므로 devtmpfsuevents를 수신하는 프로그램 또는 (이전 시스템의 경우) 프로그램이 필요합니다 .

물론 이러한 많은 것들이 mdev물론 다른 프로그램에 의해 쉽게 수행 될 수 있습니다 . 내 요점은 정적 /etc/MAKEDEV스크립트가 더 이상 작동하지 않는다는 것입니다 ...

따라서 기본적으로 부팅 복잡성에 관해서는 udev가 가장 걱정할 것입니다.

몇 가지 대안이 있습니다.

• 간단히 적절한 세트가 chmod, chown, ln부트 스트랩의 일부로 실행되는 스크립트, 그리고 그와 같은 명령을.
• 시스템 systemd-udev프로젝트의 일부인 플러그 앤 플레이 관리자 인를 사용하십시오.
• systemtoo가 크게 분기 된 포크 인 Gentoo 's를eudev 사용하십시오 systemd-udev.
• 사용 Devuan의vdev Devuan의 일부입니다 주드 넬슨에 의해 개발 된 플러그 앤 플레이 관리자입니다,.
• mdev다른 답변과 반대되는을 사용 하면 젠투가 아닙니다. BusyBox에 내장 된 플러그 앤 플레이 관리자입니다 .
• Dimitris Papastamos가 개발 한 플러그 앤 플레이 관리자 인 Sucklessmdev 를 사용하십시오 .
• BusyBox와 호환되는 구성 이지만 자체 소켓 처리를 수행하고 LISTEN 프로토콜을 이해하지 못하는 Laurent Bercot를mdevd 사용하십시오 mdev.

첫 번째와는 별도로, 장치에 대한 커널 알림 이벤트에 반응하는 방법을 설명하는 규칙 세트가 필요합니다. 명백하게.

/proc/sys/kernel/hotplug두 가지와 같이 설계된 프로그램을 가져 mdev오고 netlink 소켓을 듣고 해당 프로그램을 생성하여 해당 프로그램을 조정하고 직렬화하는 도구도 있습니다.

• 로랑 Bercot 오래입니다 s6-netlink-listener및s6-uevent-spawner
• netlink-datagram-socket-listen 과 plug-and-play-event-handler에서 요기 도구 세트

udev? 가장 좋은 대안은 사용하지 않는 것입니다. 그리고 그것을 사용하지 않는 방법을 배움으로써 Linux와 * NIX 세계는 더 논리적으로 이해되기 시작할 것입니다.

가장 장기적인 대안은 정적 장치를 사용하는 것입니다 (주 참조). 드라이버가 있으면 Linux 커널이 핫 플러깅을 관리합니다. 나는 udevd를 달리지 않는 것을 선호합니다.

dbus는 또 다른 문제입니다. 그것은 당신의 시스템을 느리게하지만, 끊임없이 변화하는 스크립트 사람들의 세계는 그것을 좋아합니다. 따라서 웹 브라우저 나 스크립트 백엔드가있는 응용 프로그램과 같은 많은 것들을 수정해야합니다 (해당 항목없이 시작되거나 다시 작성되거나 다른 응용 프로그램에 덤프 됨).

참고 : 플래시 드라이브 나 DVD 장치를 연결하는 경우 dmesg|tail마운트 할 장치 이름을 확인하는 데 사용 하십시오. 장치가 문자 또는 블록 장치 인 경우 학습은 컴퓨터 하드웨어 세계에서 기본적인 시스템 지식입니다. Linux에서는 오픈 소스이므로 임베디드뿐만 아니라 Linux에 대해서도 많이 확인하십시오 . Linux (Solaris, HPUX, AIX 등)와 같은 모든 * NIX의 간단한 논리 (철학 아님)를 더 광범위하게 이해하는 것이 가장 좋습니다.

Udev, dbus, gconf / dconf, systemd, gnome-shell, Gnome, Glib, mono 및 Fedora는 RTFM을 사용할 수 없거나 자동으로 업데이트되는 (매끄럽지 만) 느리지 만 시간이 오래 걸리는 사람들에게 적합합니다. 당밀, 버기, 반쯤있는 리눅스보다. (정말 끔찍한 곳, 비슷한 경험을 웹에서 찾아보십시오).

그런 다음 시스템 부팅은 udevd를 실행합니다. 그러나 will change재부팅시 장치 부 번호가 있기 때문에 udev가 필요하다고 주장 합니다. Udev의 raison d' etre는 매 턴마다 모순되는 것처럼 보입니다. 누구에게 문의하든 파일의 위치는 항상 잘못된 것 같습니다. 신뢰하거나 freedesktop.org를 신뢰하지 마십시오.

udev가 systemd로 알려진 그 공포에 흡수되는 것 외에도, 나는 / etc / udev 정크로 무엇을하는지 모르겠습니다. 그리고 udev 규칙을 작성하는 것이 어떤 것보다 낫습니다. 젠투 사람들은 그것에 매달리고 싶어하고 시스템을 만들 필요가없는 것처럼 보이기 때문에 그것을 eudev에 포크했습니다.

엄청나게 빠르고 불쾌한 시스템을 원치 않으면 Linux 기본 사항을 사용하십시오.