그 문제에있어서 많은 정적 파일에서 무엇이 잘못 /dev되었습니까? 개발자가이 바퀴를 3 배나 ( devfs-> udev + HAL-> udev) 다시 발명 할만큼 충분히 불만족스럽고 , 이제 그랜드 Unified Init 프로그램에도 4 번 들어갑니다.
몇 년 전 리눅스를 처음 사용하기 시작했을 때 “모든 것이 파일”이라는 주장에도 불구하고 /dev/eth0“패킷”장치 유형이기는하지만 문자 나 블록 장치가 아니기 때문에 나중에 의미가 없다고 생각합니다. 흥미로울 것입니다 …). 그렇다면 char 및 block 장치 파일 트리를 처리하는 프로그램이 네트워크 장치를 담당하는 이유는 무엇입니까? “유연성”에 대한 모호한 참조를 보았지만 ifconfig (8)이 /proc/net/dev무엇을 살펴보면 무엇을 추가 합니까? 예를 들어 NetworkManager는 udev어느 팀도 작성하고 싶지 않은 에 의존하기 때문에 Net 또는 OpenBSD에 곧있을 수 없습니다 . 내가 뭘/dev즉, 이미 커널에 의해 다양한 방법으로 노출되어있다 (그리고 그들 중 누구도를 /dev!).
핫 플러깅 때문입니까? 커널이 물리적 버스를 듣고 “장치 추가”메시지에 적절한 모듈을로드하는 데 문제가 있습니까? 아니면, 실제 관리자가 그렇게하지 않습니까? 나는 2000 년대 초에 서버가 예기치 않은 순서로 네트워크 카드를 초기화한다는 것을 기억하고 있으며, 사용자 이름에서 그 이름을 결정하는 것이 합리적이라고 생각하지만 (그 당시에는 고치기가 어렵지 않았지만) 바퀴벌레의 망치처럼 보입니다. (또는 그 문제가 유스 케이스에 부딪 칠 수도 있습니다. 제 경험 인 랙 마운트 서버 나 PC보다 훨씬 어렵지는 않습니다.)
그래서 내 질문을 명확하게 말하면 : udev가 실제로 어떤 문제를 해결하고 devfs, HAL 및 / 또는 평범한 오래된 파일이 어떻게 문제를 해결하지 못했습니까? 여러 가지 (핫 플러깅, 일반 장치 관리, 네트워크 장치 관리, 장치 이름 지정, 드라이버 우선 순위 등)가 모두 하나의 프로그램이되는 특별한 이유가 있습니까?
답변
두 가지 더 : Linux가 엔터프라이즈 및 기타 대형 서버로 이동함에 따라 정적 /dev이 손상 될 수있었습니다. 소비자와 기업 모두에서 첨단 기술은 정적 / dev를 농담으로 노출시키고있었습니다. [이 답변은 왜 devfs가 udev로 바뀌 었는지에 대한 배경 지식을 더 채우지 못합니다].
소 숫자 공간 소진
/dev파일은 주 번호와 부 번호로 커널 내부에서 식별됩니다. 커널은 실제로 이름에 신경 쓰지 않았습니다 (예를 들어, mv /dev/sda /dev/disk-1프로그램은 어디에서 찾을 지 모르지만 계속 작동 할 수 있습니다).
static을 사용하면 /dev존재할 수있는 모든 잠재적 장치에 대해 주 / 부 번호를 할당해야합니다. 이 수치는 주문형이 아닌 배포판의 일부로 배송되므로 전 세계적으로 고유해야합니다. 문제는 각 8 비트 숫자이며 범위는 0-255입니다.
예를 들어 Linux는 예를 들어 8,0은 sda, 8,1은 sda1, 8,16은 sdb 등으로 시작했습니다. 그러나 사람들은 특히 파이버 채널과 같은 것을 고려할 때 점점 더 많은 디스크를 컴퓨터에 추가했습니다. 따라서 어느 시점에서 더 많은 디스크를 위해 주요 번호 65–71이 추가되었습니다. 나중에 주요 숫자는 128–135입니다. 그러나 사람들은 계속 더 많은 디스크를 원했습니다 …
그리고 GPT와 같은 파티션 테이블 형식이 등장하여 디스크 당 더 많은 파티션을 지원합니다. 물론 다양한 RAID 컨트롤러, 논리 볼륨 관리 등과 같은 다른 장치도 많은 공간을 차지하고있었습니다.
최종 결과는 LANANA Linux 장치 목록 에서 확인할 수 있습니다 . 2.6리스트 (여전히 유일하게 존재하는리스트)를 보면 200 개 (최대 : 255)의 많은 블록 주요 숫자가 사용됩니다. 분명히 숫자가 소진되었을 것입니다.
더 큰 숫자로 변경하는 것은 쉽지 않았습니다. 커널 ABI를 변경합니다. 파일 시스템에 따라 디스크 레이아웃이 변경됩니다. 그러나 물론 이러한 장치의 대부분 은 하나의 시스템에 존재하지 않았으며 (예를 들어 SCSI 디스크가 부족한 경우에도) 많은 무료 항목이 있었을 것입니다. 아마도 IBM XT 하드 디스크가 필요하지 않았을 것입니다. 예를 들어.
dynamic /dev을 사용하면 배포판에서 장치 번호를 제공하지 않아도됩니다. 더 이상 전 세계적으로 고유하지 않아도됩니다. 부츠 전체에서 고유하지 않아도됩니다.
장치 이름을 예측할 수 없었습니다
예전에는 모든 것에 숫자를 쉽게 할당 할 수있었습니다. 보드에는 두 개의 IDE 채널이 있습니다. 각 IDE 채널은 하나의 마스터와 하나의 슬레이브를 지원했습니다. 채널 순서 및 마스터-슬레이브 순서로 할당 할 수 있습니다. 그래서 hda제 채널 마스터가된다; hdb첫 번째 채널, 슬레이브; hdc두 번째 채널, 마스터; 그것들은 예측 가능하고 안정적이었습니다. 새 드라이브를 추가하거나 제거하면 변경 될 수 있지만 하드웨어 변경이 없으면 정적입니다.
당신은 넣을 수있는 /dev/hda1당신에 /etc/fstab하고, 작업을 유지 적어도 결석 하드웨어 변경 거라고 확신합니다.
IDE는 그렇게 작동했습니다. 그 후에는 아무것도 없습니다.
SATA는 간단합니다 : 하나의 포트, 하나의 디스크. 그러나 그렇지 않다. 포트 승수를 허용합니다. 그리고 핫 스왑이 가능합니다. 여전히 하드웨어를 변경하지 않아도 실제로 매핑을 계속 유지할 수 있습니다.
USB가 훨씬 더 나쁩니다. 핫 스왑을 허용 할뿐만 아니라 일반적입니다. 사람들은 항상 USB 플래시 드라이브를 연결합니다. 또한 장치가 프로브하는 데 시간이 걸릴 수 있습니다. 실제로는 장치의 느낌이들 때마다 (예 : 휴대 전화에서 USB 저장 모드를 켜거나 끄는 경우) 변경할 수 있습니다. Firewire도 비슷합니다. 어느 것도 사용하지 않으면 실제로 안정적인 매핑을 만들 수 없습니다.
네트워크 연결 디스크에는 고유 한 포트 순서가 없습니다. 커널이 사용하는 순서는 순서대로입니다. 논리 볼륨과 동일합니다.
부팅 속도에 대한 탐구 또한 상황을 악화 시켰습니다. 원래 커널은 예를 들어 모든 USB 장치가 초기화 될 때까지 행복하게 앉아 오랫동안 기다릴 것입니다. 모든 SCSI 버스 등을 완전히 조사합니다. 이러한 프로브는 백그라운드 작업으로 만들어졌습니다. 부팅은 더 이상 기다리지 않습니다. 프로브가 완료되면 장치가 추가됩니다.
따라서 커널은 “어떻게 표시 되든지간에”어느 정도 남아 있습니다. 이 할 수있는 장치의 많은 유형을 의미 변경 순서마다 한 부팅 – 어떤 하나의 부팅에 있던 것은 /dev/sdb다른 부팅이었다 /dev/sdc. 이것은 정적 /dev인 농담을합니다.
개요
/dev예측할 수없는 디바이스 프로브 순서로 인해 정적 조합이 점점 더 의미가 없어지고 정적 주 / 부 숫자를 계속 할당하여 상당한 작업이 소진되지 않는 경우 Linux 개발자가 동적으로 전환하기로 선택한 이유가 분명해집니다 /dev.
답변
좋은 질문.
커널 2.6.13이 새로운 버전을 도입 한 이래로 인터페이스의 새로운 기능을 활용하기 위해 다시 작성해야하는 uevent상황이 발생했다 devfs. 따라서 어떤 방식으로 커널에 변화가 있는지에 대한 질문이 있어야합니다.
그러나 액면가를 취하면 이 Wikipedia의 기사 에서 귀하의 질문에 대한 답변을 얻을 수 있습니다 .
/ dev 디렉토리의 장치 노드가 정적 파일 세트 인 기존 Unix 시스템과 달리 Linux udev 장치 관리자는 시스템에 실제로 존재하는 장치에 대한 노드 만 동적으로 제공합니다. devfs가 비슷한 기능을 제공하는 데 사용되었지만 Greg Kroah-Hartman은 devfs보다 구현을 선호하는 여러 가지 이유를 언급했습니다.
1) udev는 지속적인 장치 이름 지정을 지원합니다. 예를 들어, 장치가 시스템에 연결되는 순서에 의존하지 않습니다. 기본 udev 설정은 저장 장치의 영구 이름을 제공합니다. 모든 하드 디스크는 고유 한 파일 시스템 ID, 디스크 이름 및 연결된 하드웨어의 물리적 위치로 인식됩니다.
2) udev는 devfs의 커널 공간과 달리 사용자 공간에서 완전히 실행됩니다. 결과적으로 udev는 이름 지정 정책을 커널 밖으로 옮기고 노드를 만들기 전에 장치의 속성에서 장치의 이름을 구성하는 임의의 프로그램을 실행할 수 있습니다. 전체 프로세스도 중단 가능하며 우선 순위가 더 낮습니다.
아마도 udev를 사용하면 race condition기본적으로 devfs와 hotplug에서 장치의 이름을 손상시키는 가능성을 피할 수 있습니다. 다시 말해, devfs를 사용하면 가장 왼쪽에있는 이더넷 포트가 호출 eth0되고 가장 오른쪽에 있는 포트를 보장 할 수있는 방법이 없었으며 eth1(순수한 예로서) 라우터 (하나의 포트에서 WAN으로, 하나의 포트에서 LAN으로)를 설정하기가 어렵습니다. 도구.
GUID를 기반으로 한 디스크의 이름 지정 체계를 채택하는 것도 또 다른 장점이며 전체 프로세스를 사용자 공간으로 이동시키는 것이 더 큰 방법입니다.이 사이트를 통해 얼마나 많은 사람들이 자신의 udev 규칙을 작성하는지 확인 했습니까?
사용자 공간에 udev를 갖는 고유의 장점에 대한 간단한 예로서이 사이트 또는 이 사이트 에서이 질문 또는 다른 질문을 확인 하십시오.