8. 질문과 답변

8.1. Making things work

여기에는 통상적인 질문과 답변이 있다.

8.2. devfs의 대안

나는 모든 devfs를 반대한 제안들과 대조해 보았고, 그것들의 한계를 설명했다.

참고: 준비중입니다.

8.2.1. 왜 데몬에서 create/remove 이벤트를 보내지 않는가?

여기에서 그러한 제안은 디바이스들이 create/remove 이벤트들을 등록할 수 있고, 데몬은 그 이벤트들을 들을 수 있는 커널의 API를 개발하자는 것이다. 그 데몬은 (디스크상의 한부분인)/dev를 생성/해제 할 것이다.

이것은 여러가지 제한을 가지고 있다:

  • 그것은 오직 커널이 부팅을 끝낸후에 모듈을 올리거나 제거하는 (또는 디바이스를 추가하거나 제거하는) 것에 대한 작업이다. 이벤트의 데이터베이스 없이는 데몬이 완전한 /dev를 만들 수 있는 방법은 없다.

  • 만약 이 스키마에 대한 데이터베이스를 추가한다면, 문제점은 사용자 공간에서 그 데이터베이스를 보여주는 방법이다. 만약 데몬에서 파이프를 통해 통과되는 이벤트 코드들의 문자열 리스트를 만든다면, 오직 데몬만이 사용할 수 있다. 나는 이 데이터를 보여주기 위한 장연적은 방법으로 devfs와 같은 파일시스템 비슷한 것을 설명할 것이다. 파일시스템으로써 그 데이터를 보여주는 것은 사용자가 사용가능한 것을 알아보기 쉽게 하고 또한 그 "데이터베이스"를 탐색하기 쉽도록 하는 스크립트를 작성하기 쉽게 한다.

  • 디바이스 노드와 드라이버 사이의 빡빡한 바인딩이 더 이상 가능하지 않다. (requiring the otherwise perfectly avoidable 테이블 검색)

  • /dev에서 모듈의 자동로딩은 생성된 디바이스 노드를 필요로 하기에 inode 탐색 이벤트를 잡을 수 없다. 이것은 커다란 셋으로부터 생성된 매우 적은수의 inode들의 드라이버에 대한 문제이다.

  • 이 기법은 root 파일시스템이 읽기 전용으로 마운트 되었을때는 사용할 수 없다.

8.2.2. scsidev에 대한 더 나은 구현

이 제안은 scsidev 프로그램을 포함시켜서 그것을 SCSI 디바이스 뿐만 아니라, 모든 디바이스를 탐색하는데에도 확장하자는 것이다. scsidev 프로그램은 /proc/scsi 를 탐색하는 방법으로 작동한다.

문제점:

  • 커널은 현재 사용가능한 모든 디바이스들의 목록을 제공하지 않는다. 모든 드라이브들이 커널 메세지를 생성하거나 /proc에 엔트리를 등록하지는 않는다.

  • devfs API와는 다르게 디바이스를 등록시키는 일정한 메커니즘이 없다.

  • 그와 같은 API를 구현하는 것은 위의 제안과 같다.

8.2.3. 램 디스크에 /dev를 넣는 것

이 제안은 램디스크를 생성하고 디바이스 노드들을 거기에 둔 후 /dev에 그것을 마운트 하자는 것이다.

문제점:

  • 이것은 루트 파일시스템을 마운트 하기 위해서는 여전히 디바이스 노드가 필요하므로 루트 파일시스템을 마운트 할때는 도움이 되지 못한다.

  • 만약 루트 디바이스 노드에도 이 기법을 사용하기 원한다면, initrd를 사용하여야 한다. 이것은 부팅 과정을 복잡하게 하고, 관리자와 설정하는 것을 더 어렵게 한다. initrd 는 쉬운 시스템 관리를 앗아감으로써 본질적으로 불투명하다.

  • 정확하게 램디스크를 위치시키기 위한 정보가 불충분하다. 그래서 우리는 그 문제를 해결하기 위해서 위의 제안으로 돌아간다.

  • ramdisc-based 해결책은 각 항목마다 일반 VFS inode와 dentry 에 대해서 284 바이트와 112 바이트의 기본적인 저장공간이 필요하므로, 더 많은 커널 메모리가 필요하다. devfs가 72 바이트를 요구하는 것과 비교해보라.

8.2.4. 아무것도 하지 않는다: 아무런 문제가 없다

때때로 사람들은 현재의 스키마가 좋다라는 주장을 듣곤 한다. 이것은 그들이 무시하는 것에 대한 것이다.

  • 디바이스 번호의 크기(메이저/마이너 번호 당 8비트)은 실제 제한사항이고, 어떤 방식으로던 수정되어야만 한다. 예를 들어 큰 SCSI 디바이스 번호를 가지는 시스템에서는 할당되지 않은 메이저 번호들을 계속 사용할 것이다. USB는 8비트의 마이너 번호 제한을 넘을 필요가 있다.

  • 단순히 디바이스 번호를 증가시키는 것만으로는 불충분하다. 많은 노력을 필요로 하는 것과는 달리, 수천개 이상의 디바이스 노드를 가지는 /dev 를 관리하는 문제를 해결하지는 못한다.

  • 거대한 /dev의 문제를 무시하는 것은 동적인 /dev를 원하는 많은 수의 합리적인 주장을 철회하거나 오래가지 못할 것이다.

  • 표준 응답: "디바이스 관리 데몬을 작성하라" 이것은 우리가 위의 제안으로 돌아가게 한다.

8.3. devfs에 대해 좋아하지 않는것

여기 devfs에 대한 불평불만이 있고, 어떤 제안과 해결책은 좀더 당신의 마음에 들것이다. 나는 모든 사람을 기쁘게 할 수 없지만, 노력하겠다 :-)

8.3.1. 나는 그 네이밍 스키마가 싫다

첫번째로, 모든 사람을 기쁘게 해 줄수 있는 네이밍 스키마는 없다는 것을 기억하라. 당신이 그 스키마가 싫어도, 다른 사람은 좋아한다. 누가 옳고 그름을 말할수 있는가? 궁극적으로, 코드를 작성하는 사람은 선택을 하고, 현재 남아있는 것은 devfs 저자와 커널 관리자(Linus)에 의해 만들어진 것을 조합하는 것이다.

그러나, 모든 것을 잃지는 않는다. 만약 자신만의 네이밍 스키마를 만들고 싶다면, 독립적인 스크립트를 작성하거나, devfsd 를 핵 하거나, devfsd 에 의해 호출되는 스크립트를 작성하는 등의 간단한 일을 하면된다. 여러분이 좋아하는 네이밍 스키마가 무엇이던지 간에 만들 수 있다.

또한, /dev로부터 devfs 네이밍 스키마의 모든 것을 제거하기를 원한다면, devfs를 아무곳이나(/devfs등의)마운트하고, /devfs/dev를 링크하여 만들 수 있다. 그것은 원한다면 devfsd를 사용함으로써 자동적으로 해결될 수도 있다.

심지어 심볼릭 링크를 사용하기보다 VFS 바인딩 키능이 링크를 만들도록 사용할 수도 있다. 이 방법은, 이 심볼릭 링크들의 "목적지"가 어디인지 알 필요가 없다.

8.3.2. 커널에서 Devfs 정책

이미 커널안에서의 정책이 있다. 디바이스 번호는 실제로 정책에 의한 것이다 (왜 내가 사용하는 디바이스 번호가 무엇인지를 커널이 지시해야만 하는가?). 이것에 대해, 커널에는 어떤 정책이 있다. 정책으로써의 디바이스 이름과 정책으로서의 디바이스 번호의 실제 차이점은 디바이스 번호는 사람에게는 의미없는 숫자이고 너무 조잡스럽기 때문에 누구도 직접적으로 사용하지 않는다는 것이다. 최소한 devfs 디바이스 이름에서는, (자신만의 네이밍 스키마를 더 할 수 있다 하더라도) 어떤 사람들은 devfs가 제공하는 이름을 직접적으로 사용할 것이다. 이것은 어떤 사람들에게는 기분 나쁜 일이다 :-)

8.3.3. Devfs는 블로트웨어(bloatware)이다

앞에서 보여진 것처럼, 이것은 전혀 진실이 아니다. 코드와 데이터 크기 모두 매우 적은 양이다.

8.4. 버그 리포트 방법

만약 devfs에 대한 버그를 알고 있다면(또는 알고 있다고 생각한다면), 다음의 단계대로 행하라:

  1. 최신의 devfs 패치를 적용했는지 확인해보라. 최신의 커널버전에 최신의 devfs 패치가 적용되지 않았을 수도 있다(Linus는 매우 바쁘다)

  2. 당신의 버그 리포트에 완전한 커널 로그 (dmesg를 사용하여)를 저장하여 포함하라. 모든 부트 메세지를 잡아내기 위한 내부버퍼의 크기를 증가시키기 위해 -s를 사용할 필요가 있을 것이다.

  3. 커널 부트 커맨드 라인에 devfs=dall를 넣고 부팅해보고 (부트로더에서 이것을 사용하는 방법은 문서를 읽도록 하라), 그 결과를 파일로 저장하라. 이것은 매우 장황스러운 일이고, 메제시 버퍼를 넘어설 수도 있지만, 할수만 있다면 더 많은 것을 잡아내도록 노력해달라.

  4. 당신의 devfsd 설정파일을 복사해 보내달라.

  5. 에게 먼저 버그 리포트를 보내라. 당신이 리눅스 커널 메일링 리스트에 버그를 리포트 한다고 해서 내가 알 것이라고 기대하지는 말라. 위에 나열된 모든 정보를 포함하고, 그외 관련이 있다고 생각하는 것을 추가시켜도 좋다. 제목에 devfs를 넣어서, 나의 메일 필터가 긴급한 상황임을 알수 있게 하라.

여기, 답장받을 기회를 향상시켜주는 질문하는 방법이 있다: http://www.tuxedo.org/~esr/faqs/smart-questions.html 만약 버그보고를 하고 싶다면, http://www.chiark.greenend.org.uk/~sgtatham/bugs.html 를 읽을 필요가 있을 것이다.

8.5. 이상한 커널 메세지

당신의 커널로그에서 devfs와 관련된 메세지를 볼 수 있을 것이다. 아래는 그 메세지들의 의미를 나열했다 (그리고 가능하다면 그 메세지와 관련해서 해야 할 것들의 목록이다)

8.6. devfsd의 컴파일 문제

보통, devfsd컴파일은 단지 소스 디렉토리에서 make를 친 후, make install (루트로)을 치는 것으로 된다. 가끔은, 잘못된 설정으로 인해 문제가 일어날 수도 있다.