여기에는 통상적인 질문과 답변이 있다.
Devfsd가 모든 퍼미션을 관리하지 않는다
당신이 적당한 이벤트를 캡쳐하고 있는지 확인하라. 예를 들어,커널이 만든 디바이스 엔트리는 REGISTER 이벤트를 발생시키지만, devfsd가 생성한 것들은 CREATE이벤트를 발생한다.
Devfsd 는 모든 REGISTER이벤트를 캡쳐하지 않는다.
앞의 항목을 보라 : 당신은 CREATE이벤트를 캡쳐할 필요가 있다.
X가 시작하지 않는다.
위에 약술된 모든 단계를 따라했는지 확인해보라.
왜 네트워크 디바이스가 devfs에 나타나지 않는가?
이것은 버그가 아니다. 네트웍 디바이스는 네임스페이스와는 완전히 분리되어 있다. 그것들은 socket(2)와 setsockopt(2)에 의해 접근되고, 따라서 디바이스 노드가 필요없다. 나는 네트웍 디바이스를 디바이스 네임스페이스에 옮길 것을 제안하였지만, 아무런 응답을 받지 못했다.
커널에 devfs가 컴파일되어 있는지 확인하는 방법은 무엇인가?
커널에 내장되어 있거나 현재 로딩되어 있는 모든 파일시스템들은 /proc/filesystems에 나타난다. 만약 devfs 엔트리가 보인다면, devfs가 컴파일되어 있는 커널이라는 것을 알수 있다. 만약 정확하게 설정하고 커널을 재컴파일 한다면, devfs는 내장되어 있을 것이다. 생각하기에 제대로 설정했음에도 /proc/filesystems에 나타나지 않는다면, 당신이 실수를 한 것이다. 일반적인 실수는:
devfs 패치를 적용하지 않은 2.2.x 커널을 사용중이다(만약 커널을 패치하는 방법을 모른다면, 대신에 2.4.x를 사용하고, 나에게 패치하는 법을 질문해서 성가시게 하지 말라)
CONFIG_EXPERIMENTAL=y 로 설정하는 것을 잊었다.
CONFIG_DEVFS_FS=y로 설정하는 것을 잊었다.
CONFIG_DEVFS_MOUNT=y로 설정하는 것을 잊었다. (만약 부팅시 devfs가 자동으로 마운트 되기를 원한다면)
make config 나 make xconfig 대신에 .config 를 직접 수정하라.
설정을 변경하고 컴파일하기 전에 make dep; make clean하는 것을 잊었다.
커널과 모듈을 컴파일 하는 것을 잊었다.
커널을 설치하는 것을 잊었다.
모듈을 설치하는 것을 잊었다
제발 버그 리포트를 보내기 전에 위의 모든 단계를 수행하였는지 두번씩 체크하도록 하라.
devfs가 /dev에 마운트되었는지 어떻게 확인하죠?
디바이스 파일시스템은 데몬과 통신하기 위해 사용되는 ".devfsd" 라 불리는 항목을 항상 생성한다. 데몬이 실행중이 아니라 할지라도, 그 항목은 존재한다. 이 항목의 존재에 대해 확인하는 것은 devfs가 마운트 되었는지 아닌지 결정하는 좋은 방법이다. 항목의 형태(i.e. 일반적인 파일, 캐릭터 디바이스, named pipe, 등등)은 사전주의 없이 바뀔수도 있다. 오직 그 항목(.devfsd:역자 주)의 존재만이 믿을만한 것이다
나는 모든 devfs를 반대한 제안들과 대조해 보았고, 그것들의 한계를 설명했다.
참고: 준비중입니다.
여기에서 그러한 제안은 디바이스들이 create/remove 이벤트들을 등록할 수 있고, 데몬은 그 이벤트들을 들을 수 있는 커널의 API를 개발하자는 것이다. 그 데몬은 (디스크상의 한부분인)/dev를 생성/해제 할 것이다.
이것은 여러가지 제한을 가지고 있다:
그것은 오직 커널이 부팅을 끝낸후에 모듈을 올리거나 제거하는 (또는 디바이스를 추가하거나 제거하는) 것에 대한 작업이다. 이벤트의 데이터베이스 없이는 데몬이 완전한 /dev를 만들 수 있는 방법은 없다.
만약 이 스키마에 대한 데이터베이스를 추가한다면, 문제점은 사용자 공간에서 그 데이터베이스를 보여주는 방법이다. 만약 데몬에서 파이프를 통해 통과되는 이벤트 코드들의 문자열 리스트를 만든다면, 오직 데몬만이 사용할 수 있다. 나는 이 데이터를 보여주기 위한 장연적은 방법으로 devfs와 같은 파일시스템 비슷한 것을 설명할 것이다. 파일시스템으로써 그 데이터를 보여주는 것은 사용자가 사용가능한 것을 알아보기 쉽게 하고 또한 그 "데이터베이스"를 탐색하기 쉽도록 하는 스크립트를 작성하기 쉽게 한다.
디바이스 노드와 드라이버 사이의 빡빡한 바인딩이 더 이상 가능하지 않다. (requiring the otherwise perfectly avoidable 테이블 검색)
/dev에서 모듈의 자동로딩은 생성된 디바이스 노드를 필요로 하기에 inode 탐색 이벤트를 잡을 수 없다. 이것은 커다란 셋으로부터 생성된 매우 적은수의 inode들의 드라이버에 대한 문제이다.
이 기법은 root 파일시스템이 읽기 전용으로 마운트 되었을때는 사용할 수 없다.
이 제안은 scsidev 프로그램을 포함시켜서 그것을 SCSI 디바이스 뿐만 아니라, 모든 디바이스를 탐색하는데에도 확장하자는 것이다. scsidev 프로그램은 /proc/scsi 를 탐색하는 방법으로 작동한다.
문제점:
커널은 현재 사용가능한 모든 디바이스들의 목록을 제공하지 않는다. 모든 드라이브들이 커널 메세지를 생성하거나 /proc에 엔트리를 등록하지는 않는다.
devfs API와는 다르게 디바이스를 등록시키는 일정한 메커니즘이 없다.
그와 같은 API를 구현하는 것은 위의 제안과 같다.
이 제안은 램디스크를 생성하고 디바이스 노드들을 거기에 둔 후 /dev에 그것을 마운트 하자는 것이다.
문제점:
이것은 루트 파일시스템을 마운트 하기 위해서는 여전히 디바이스 노드가 필요하므로 루트 파일시스템을 마운트 할때는 도움이 되지 못한다.
만약 루트 디바이스 노드에도 이 기법을 사용하기 원한다면, initrd를 사용하여야 한다. 이것은 부팅 과정을 복잡하게 하고, 관리자와 설정하는 것을 더 어렵게 한다. initrd 는 쉬운 시스템 관리를 앗아감으로써 본질적으로 불투명하다.
정확하게 램디스크를 위치시키기 위한 정보가 불충분하다. 그래서 우리는 그 문제를 해결하기 위해서 위의 제안으로 돌아간다.
ramdisc-based 해결책은 각 항목마다 일반 VFS inode와 dentry 에 대해서 284 바이트와 112 바이트의 기본적인 저장공간이 필요하므로, 더 많은 커널 메모리가 필요하다. devfs가 72 바이트를 요구하는 것과 비교해보라.
때때로 사람들은 현재의 스키마가 좋다라는 주장을 듣곤 한다. 이것은 그들이 무시하는 것에 대한 것이다.
디바이스 번호의 크기(메이저/마이너 번호 당 8비트)은 실제 제한사항이고, 어떤 방식으로던 수정되어야만 한다. 예를 들어 큰 SCSI 디바이스 번호를 가지는 시스템에서는 할당되지 않은 메이저 번호들을 계속 사용할 것이다. USB는 8비트의 마이너 번호 제한을 넘을 필요가 있다.
단순히 디바이스 번호를 증가시키는 것만으로는 불충분하다. 많은 노력을 필요로 하는 것과는 달리, 수천개 이상의 디바이스 노드를 가지는 /dev 를 관리하는 문제를 해결하지는 못한다.
거대한 /dev의 문제를 무시하는 것은 동적인 /dev를 원하는 많은 수의 합리적인 주장을 철회하거나 오래가지 못할 것이다.
표준 응답: "디바이스 관리 데몬을 작성하라" 이것은 우리가 위의 제안으로 돌아가게 한다.
여기 devfs에 대한 불평불만이 있고, 어떤 제안과 해결책은 좀더 당신의 마음에 들것이다. 나는 모든 사람을 기쁘게 할 수 없지만, 노력하겠다 :-)
첫번째로, 모든 사람을 기쁘게 해 줄수 있는 네이밍 스키마는 없다는 것을 기억하라. 당신이 그 스키마가 싫어도, 다른 사람은 좋아한다. 누가 옳고 그름을 말할수 있는가? 궁극적으로, 코드를 작성하는 사람은 선택을 하고, 현재 남아있는 것은 devfs 저자와 커널 관리자(Linus)에 의해 만들어진 것을 조합하는 것이다.
그러나, 모든 것을 잃지는 않는다. 만약 자신만의 네이밍 스키마를 만들고 싶다면, 독립적인 스크립트를 작성하거나, devfsd 를 핵 하거나, devfsd 에 의해 호출되는 스크립트를 작성하는 등의 간단한 일을 하면된다. 여러분이 좋아하는 네이밍 스키마가 무엇이던지 간에 만들 수 있다.
또한, /dev로부터 devfs 네이밍 스키마의 모든 것을 제거하기를 원한다면, devfs를 아무곳이나(/devfs등의)마운트하고, /devfs에 /dev를 링크하여 만들 수 있다. 그것은 원한다면 devfsd를 사용함으로써 자동적으로 해결될 수도 있다.
심지어 심볼릭 링크를 사용하기보다 VFS 바인딩 키능이 링크를 만들도록 사용할 수도 있다. 이 방법은, 이 심볼릭 링크들의 "목적지"가 어디인지 알 필요가 없다.
이미 커널안에서의 정책이 있다. 디바이스 번호는 실제로 정책에 의한 것이다 (왜 내가 사용하는 디바이스 번호가 무엇인지를 커널이 지시해야만 하는가?). 이것에 대해, 커널에는 어떤 정책이 있다. 정책으로써의 디바이스 이름과 정책으로서의 디바이스 번호의 실제 차이점은 디바이스 번호는 사람에게는 의미없는 숫자이고 너무 조잡스럽기 때문에 누구도 직접적으로 사용하지 않는다는 것이다. 최소한 devfs 디바이스 이름에서는, (자신만의 네이밍 스키마를 더 할 수 있다 하더라도) 어떤 사람들은 devfs가 제공하는 이름을 직접적으로 사용할 것이다. 이것은 어떤 사람들에게는 기분 나쁜 일이다 :-)
앞에서 보여진 것처럼, 이것은 전혀 진실이 아니다. 코드와 데이터 크기 모두 매우 적은 양이다.
만약 devfs에 대한 버그를 알고 있다면(또는 알고 있다고 생각한다면), 다음의 단계대로 행하라:
최신의 devfs 패치를 적용했는지 확인해보라. 최신의 커널버전에 최신의 devfs 패치가 적용되지 않았을 수도 있다(Linus는 매우 바쁘다)
당신의 버그 리포트에 완전한 커널 로그 (dmesg를 사용하여)를 저장하여 포함하라. 모든 부트 메세지를 잡아내기 위한 내부버퍼의 크기를 증가시키기 위해 -s를 사용할 필요가 있을 것이다.
커널 부트 커맨드 라인에 devfs=dall를 넣고 부팅해보고 (부트로더에서 이것을 사용하는 방법은 문서를 읽도록 하라), 그 결과를 파일로 저장하라. 이것은 매우 장황스러운 일이고, 메제시 버퍼를 넘어설 수도 있지만, 할수만 있다면 더 많은 것을 잡아내도록 노력해달라.
당신의 devfsd 설정파일을 복사해 보내달라.
나 에게 먼저 버그 리포트를 보내라. 당신이 리눅스 커널 메일링 리스트에 버그를 리포트 한다고 해서 내가 알 것이라고 기대하지는 말라. 위에 나열된 모든 정보를 포함하고, 그외 관련이 있다고 생각하는 것을 추가시켜도 좋다. 제목에 devfs를 넣어서, 나의 메일 필터가 긴급한 상황임을 알수 있게 하라.
여기, 답장받을 기회를 향상시켜주는 질문하는 방법이 있다: http://www.tuxedo.org/~esr/faqs/smart-questions.html 만약 버그보고를 하고 싶다면, http://www.chiark.greenend.org.uk/~sgtatham/bugs.html 를 읽을 필요가 있을 것이다.
당신의 커널로그에서 devfs와 관련된 메세지를 볼 수 있을 것이다. 아래는 그 메세지들의 의미를 나열했다 (그리고 가능하다면 그 메세지와 관련해서 해야 할 것들의 목록이다)
devfs_register(fred):could not append to parent, err: -17
당신은 그 에러코드가 의미하는 바를 확인할 필요가 있지만, 보통 17은 EEXIST를 의미한다. 이것은 드라이버가 디렉토리에 fred 항목을 생성하려고 했지만, 같은 이름의 항목이 이미 존재한다는 것을 나타낸다. 이것은 종종 퍼미션을 복구하기 위한 수단으로 /dev에 inode들을 풀어놓으려는 스크립트가 잘못되었을때 일어난다. 이 메세지는 그 디바이스 노드가 여전히 그 드라이버에 접근하도록 허용하기 때문에 (온 정성을 다하여:-) devfs=only부트 옵션을 사용하더라도) 위험하다. 이러한 불필요한 메세지를 제거하기 원한다면, devfsd-v1.3.20으로 업그레이드 하고, 퍼미션을 저장하기 위하여 추천된 RESTORE 지시자를 사용하라.
devfs_mk_dir(bill): using old entry in dir: c1808724 ""
이것은 드라이버가 부모디렉토리가 같은 이름을 가지는 bill이라 불리는 디렉토리를 생성하려고 한다는 것을 제외하고위의 메세지와 유사하다. 이 경우에, 드라이버가 작동을 올바르게 계속하기 위해서, 옛 항목이 그 드라이버에 주어지고 재사용된다. 2.5 커널에서는, 그 드라이버는 NULL 항목이 주어지고, 따라서, 어떤 환경에서는 요청된 디바이스 노드를 생성하지 못할 것이다. 이것의 해결책은 위와 같다
보통, devfsd컴파일은 단지 소스 디렉토리에서 make를 친 후, make install (루트로)을 치는 것으로 된다. 가끔은, 잘못된 설정으로 인해 문제가 일어날 수도 있다.
DEVFSD_NOTIFY_DELETE에 관련된 에러메세지
이것은 /usr/include/linux나 /usr/src/linux에 예전의 커널 헤더를 가지고 있기 때문에 일어난다. KERNEL_DIR변수를 (만약 /usr/src/linux에 새 커널소스를 설치하지 않았다면) make에 전달하거나, /usr/include/linux에 커널 소스에 있는 devfs_fs.h를 복사하면 된다.