문서읽기를 좋아하는 사람은 없다. 사람들은 바로 얻고 수행하기를 원한다. 따라서 이번 부분에서는 빠르게 /dev 상에 devfs를 마운트 하여 수행하는데 있어 필요한 단계 를 설명할 것이다. 이번 단계를 건너뛰어라. 그러면 당신은 거의 부팅할수 없는 시스템을 가진채 끝날 것이다. 아래의 부분들은 좀더 자세한 부분에 대해 설명하고 있고, 필수적이지 않은 설정옵션에 대해 논의할 것이다.
OK, 당신이 이부분을 읽고 있다면, 나는 당신이 devfs를 사용하기를 원한다고 생각할 것이다. 첫번째로 당신은 /usr/src/linux에 최신의 커널소스를 포함하고 있는지 확실하게 해야한다. 그리고 디바이스 관리 데몬인 devfsd 를 컴파일 할 필요가 있다. 이것은 http://www.atnf.csiro.au/~rgooch/linux/ 에서 얻을수 있다. 그 커널은 옛 버전의 네이밍 스키마와는 상당히 다른 네이밍 스키마를 가지기 때문에 예전의 네이밍 스키마가 깨지지 않고 계속 사용할 수 있도록하는 소프트웨어와 설정파일인 devfsd를 설치할 필요가 있다.
devfsd를 컴파일 하고 설치하라. 당신은 예전 네이밍 스키마에 대하여 호환성을 가지는 심링크를 제공하는 기본 설정파일인 /etc/devfsd.conf를 제공받을 것이다. 충분한 지식을 얻기 전까지 이 파일을 수정하지 말라. 충분한 지식을 가지고 있다고 생각한다 할지라도, 아래에서 부팅된 devfs가 가능한 시스템과 이것이 제대로 작동하는지에 대해 검증이 끝날때까지 수정하지 말라.
이제 devfsd가 가장 처음(파일시스템의 체크가 일어나기 전에)에 시작되도록 메인 시스템의 부트 스크립트를 수정해야 한다. 가금 /etc/rc.d/rc.sysinit이 SysV 형식의 부트 스크립트와 함께 시스템에서 메인 부트 스크립트로 사용된다. BSD 형식의 부트 스크립트를 가지는 시스템에서는 /etc/rc 도 사용된다. /sbin/rc도 체크해보라.
잘못된 소프트웨어가 디바이스 네임에 대해 가정하기 때문에 일어나는 문제점들이 있다. 자세하게 말하면, 어떤 소프트웨어는 심볼릭 링크로 된 디바이스를 사용하지 못한다. 만약 libc5 를 사용하는 시스템을 사용하고 있다면, libc5.4.44를 설치해라(만약 libc5.4.46을 사용하고 있다면 올바르게 작동하는 libc5.4.44로 다운그레이드하라). 만약 glibc에 기초한 시스템을 사용한다면 glibc 2.1.3 이상인지 확인해야 한다.
PAM(Pluggable Authentication Modules)은 더 나은 사용자 인증과 서비스를 제공하기 때문에 유연한 메커니즘으로 평가받고 있다. 불행하게도, 그것은 깨지기 쉽고, 복잡하고 문서화 되어 있지 않다(레드햇 6.1과 다른 배포판을 확인해보라). PAM은 심볼릭링크와는 문제를 일으킨다. 다음의 줄을 /etc/securetty 파일에 추가시켜라 :
이것은 보안을 약화시키지 않을 것이다. 만약 2.10.h 이전의 util-linux 버전을 사용하고 있다면 그 이후의 버전으로 업그레이를 하기 바란다. 만약 업그레이드 할 수 없다면, 다음의 줄을 /etc/securetty 파일에 추가하라 :
이것은 네트워크를 통한 루트의 로그인을 허용하기 때문에(패스워드는 요구된다) 보안을 약화시킨다. 그러나, 심링크를 취급하는데 있어서 문제가 있기 때문에, 나는 어떤 경우에라도 제공되는 보안레벨에 의심을 가지고 있다. (역자 주 : PAM이 심링크에 문제점을 보이기 때문에, 어차피 보안에는 문제점이 있다는 말)
필수적이지는 않지만, 좀더 devfs에 밀접하도록 하는 패치의 일환으로 XFree86 4.0으로 업그레이드 하는 것은 좋은 생각이다. 만약 그렇게 하지 않는다면, 일반 사용자가 startx를 할수 있도록 /etc/security/console.perms에 다음의 패치를 적용해야 할 것이다. 모든 배포판이 이 파일을 가지고 있는 것은 아니므로(e.g. 데비안) 이것이 존재하지 않는다고 해도 걱정할 필요는 없다.
만약 패치가 적용되지 않는다면, 다음과 같이 변경하라.:
을
으로 수정하면 된다.
나는 /dev/pts에 마운트된 devpts가 제대로 작동하지 않는다는 보고를 받았다. devfs는 /dev/pts를 관리하므로, 더 이상 devpts를 마운트할 필요는 없다. /etc/fstab파일을 수정해서 마운트되지 않도록 하거나, 커널 설정에서 devpts를 사용하지 않도록 하라.
모든 드라이버가 devfs를 지원하지는 않는다. 만약 이러한 드라이버 중에 하나를 가지고 있다면, 적당한 때에 디바이스 노드를 생성하도록 부팅시에 사용할 수 있는 스크립트나 tarfile를 작성하는 것이 필요할 것이다. 5.3절 은 이부분을 설명하고 있다. 5.3절 은 devfs를 지원하는 드라이버들의 목록이다.
많은 배포판들이 XFree86과 GPM의 마우스 디바이스를 /dev/mouse로 설정한다. 나는 이것을 원래와 다르게 우회해서 추가하기 때문에 좋지 못한 생각이라고 생각한다. 만약 당신이 설정파일에서 살펴볼 때, /dev/mouse를 보게 된다면 마우스가 참조된 곳이 어디인지 궁금하게 여길 것이다. 따라서 나는 /etcX11/XF86Cnfig파일(그리고 GPM 설정 파일)에 실제 마우스 디바이스(예를 들어,/dev/psaux 와 같은)를 기입하는 것을 추천한다.
다른 방법으로는 위에 설명된 지원되지 않는 드라이버를 위한 테크닉을 사용해도 된다.
마지막으로, devfs가 커널에에서 컴파일 되도록 해야 한다. 가장 좋아하는 커널 설정툴(예를 들면, make config 또는 make xconfig)을 사용하여 CONFIG_EXPERIMENTAL=y, CONFIG_DEVFS_FS=y 그리고 CONFIG_DEVFS_MOUNT=y 로 설정하고 make dep;make clean 하고 커널과 모듈을 재컴파일 하라. 부팅시에 devfs가 /dev 에 마운트 될 것이다.
만약 부팅시에 문제(예를 들어, 설정 단계를 잊었다던지 하는)가 발생한다면, 커널 부트 커맨드 라인에 devfs=nomount를 넣고 통과할 수 있다. 이것은 커널이 부팅시에 devfs를 /dev에 마운팅 하는 것을 막아준다. /proc/partitions, irrespective of whether devfs is mounted.
일반적으로 CONFIG_DEVFS_FS=y로했지만 /dev에 마운트되지 않도록 만들어진 커널은 안전하다, 또한 설정의 변경도 필요없다. 주의를 기울여야 할 한가지 예외는 LABEL= 지시자가 /etc/fstab에 사용되었을 때이다. 이런 경우에는 정상적으로 부팅할 수 없을 것이다. 이것은 mount(8) 프로그램이 그 볼륨 레이블을 찾는 과정의 일부분으로 /proc/partitions를 사용하고, 찾은 디바이스 이름이 CONFIG_DEVFS_FS=y로 설정하는 것이 /proc/partitions 에서 그 이름을 변경시키고, devfs가 마운트 되었는지 상관하지 않기 때문에 사용불가능하게 되기 때문이다.
이제 필요한 모든 단계를 끝냈다. 이제 당신의 빛나는:-) 새로운 커널을 부팅할 준비가 되었다. 즐겨보라.
OK, 이제 devfs가 사용가능한 시스템을 부팅시켰고, 모든 것이 제대로 작동한다. 이제 설정파일을 변경시킬 필요를 느낄 것이다(일반적으로 설정대상은 /etc/fstab와 /etc/devfsd.conf이다). 제대로 작동하는 시스템을 갖고 있기 때문에, 설정을 변경하고나서 제대로 작동하지 않더라도, 디폴트로 설정파일을 복구하면 잘 작동한다는 것을 알 수 있다.
만약 디바이스 파일을 생성하기 위하여 mknod(2)를 사용하지 않고 소유권/퍼미션을 변경하기 위해 chmod(2) 또는 chown(2)을 사용하지 않는다면 inode의 ctime는 0(12 am, 1-JAN-1970, GMT)으로 남겨질 것이다. 이후의 ctime을 가지는 것들은 소유권/퍼미션의 변화가 있을 것이다. 따라서, 간단한 스크립트 또는 프로그램을 사용하여 셧다운하기 전에 모든 변경된 inode들을 묶는데 사용한다. 효과적이긴 하지만 이것을 적용하기 위해서는 많은 고려사항이 있다.
더 나은 접근방법은 퍼미션을 저장하고 북구하는데 devfsd를 사용하는 것이다. 이것은 퍼미션에서의 변경을 기록하기 위해서 설정되고, 데이타베이스(실제로는 디렉토리 트리)에 저장하고, 부팅시에 복구할 것이다. 이것은 현재의 퍼미션을 저장하는데 있어서 효율적인 방법이며 효과적인 결과를 보여준다(알수 없는 미래의 시간에 퍼미션을 저장하는 tar 의 접근과는 다르게)
devsd에 제공되는 기본설정파일은 지속적인 관리가 가능하도록 하기 위해 주석이 달린 설정부분을 가지고 있다.
만약 어떤 방법으로던 tar 접근을 사용하기로 결정했다면, tar은 새로운 디바이스 노드를 생성하기 전에 먼저 inode를 unlink(2) 할 것이라는 것을 주의하라. unlink(2)는 devfs 엔트리와 디바이스 드라이버 사이의 연결을 끊어버리는 효과를 가진다. 만약 부팅 옵션에서 "devfs=only"를 사용하고 있다면, 모듈을 적재하기 위해 필요한 디바이스 드라이버에 대한 통로를 잃게 된다. 나는 이것을 tar의 버그라고 생각하고 있다(실제로 tar가 inode를 먼저 unlink(2)할 필요는 없다)
다른 방법으로는, 디바이스의 좀더 철학적인 퍼미션 관리를 제공하기 위하여 devfsd를 사용할 수도 있다. 당신은 디바이스당 하나의 엔트리를 할당하는 진부한 방법보다, 하나의 설정을 통하여 모든 디바이스 그룹에 대하여 퍼미션을 저장할 수 있다.
만약 devfs가 /dev에 마운트 된채로 disc-baed /dev에 디바이스의 퍼미션을 저장하거나 복구하기를 원한다면 그렇게 할 수도 있다. 이것은 2.4.x 커널 (실제로는, 2.3.99 이후)의 VFS 바인딩 기능을 필요로 한다. 이 기능을 설정하기 위해서는 아래와 같이 하라:
부팅시에 devfs가 마운트 되지 않도록하라
/dev-state디렉토리를 만들어라
리붓
만약 VFS 바인딩을 지원하지 않는 오래된 커널을 사용중이라면, /dev에 마운트되어 있는 퍼미션 데이타베이스를 가져올 수 없을 것이다. 그러나 그 데이타베이스를 복구하기 위하여 일반 디렉토리를 만들 수 있다. 위의 /etc/devfsd.conf파일은 여전히 사용가능 할 것이다. 당신은 devfsd를 인스톨 하기에 앞서 /dev-state디렉토리를 만들어야 한다. 만약 /dev에 예전의 퍼미션을 가지고 있다면, 새로운 디렉토리에 디바이스 노드들을 카피(또는 move)하면 된다.
가장 좋은 방법은 /dev에 마운트되어 있는 퍼미션의 데이터베이스를 가져오는 것이다. 그 이유는 디바이스 노드들을 /dev-state에 복사할 필요가 없고, /dev-state(devfs를 위한) 과 /dev/(devfs를 사용하지 않을 경우에) 사이에 퍼미션을 복사할 필요가 없이 devfs와 devfs를 사용하지 않는 커널을 바꿀 수 있기 때문이다.
현재, 커널에서 모든 드라이버들이 devfs를 사용하도록 수정되지는 않았다. 여전히 devfs가 지원되지 않는 디바이스 드라이버들은 자동으로 devfs에 나타나지 않을 것이다. 이러한 드라이버들에 대한 디바이스를 생성하는 가장 간단한 방법은 필요한 디바이스 노드들을 포함하고 있는 tarfile을 푸는 것이다. 이것을 부트 스크립트에 넣어도 된다. 이제 당신의 모든 드라이버들은 전처럼 작동할 것이다.
고무적이게도 대부분의 사람들에게 devfs는 대부분의 기능을 잃지 않고 (예를 들어 다양한 디바이스에 대한 접근 상실) /dev 위에 devfs디렉토리를 마운트 할 수 있는 충분한 지원을 한다. 1998 년 1월 22일 이후 (devfs 패치 버전 10)부터 나는(저자는) 이 방법(devfs)를 운영하고 있다. 내가 가지고 있는 모든 디바이스들은 devfs에 나타나므로 나는 아무것도 잃은 것이 없다.
| 경고 |
만약 당신의 설정이 예전방식의 디바이스 이름(예를 들어 /dev/hda1 , /dev/sda1)을 필요로 한다면, 호환엔트리를 유지하도록 devfsd를 설치하고 설정해야 한다. 당신이 이것을 필요로 할 것이라는 것은 거의 확실하다. 커널이 루트 디바이스에 대해 호환항목을 생성하기 때문에 initrd를 필요로 하지 않는다는 것을 기억하라. |
만약 Unix98 PTYs를 사용하기 있다면 devfs 가 /dev/pts를 관리할 수 있기 때문에 더 이상 devpts 를 마운트할 필요가 없다는 것을 기억하라. 이것은 devpts를 컴파일 하고 설치할 필요가 없기 때문에, 약간의 램을 절약한다. glibc의 어떤 버전은 devfs 시스템에서 Unix98 pty를 취급하는데 버그를 가지고 있다는 것을 명심하라. 수정을 위해서는 glibc 메인테이너와 연락하라. Glibc 2.1.3 은 수정되었다.
만약 devfsd를 설치하지 않았다면 /etc/fstab를 수정하는 것에서부터 다른 것들도 수정해야 한다는 것을 명심하라. (X 서버와 같은) 어떤 소프트웨어는 그 소스에 디바이스 이름을 고정시켜 놓는다. 실제로 호환 엔트리를 생성하는데 devfsd를 사용하는 것이 훨씬 쉽다. 당신은 당신의 시스템을 devfsd가 호환항목을 생성하도록 제한하면서 서서히 새로운 디바이스 이름(예를 들어, /etc/fstab부터 시작하여)을 사용하도록 할수 있다.
DEVFS가 가능한 커널을 부팅하기 전에 DEVFSD를 설치하였는지 확인하라!!
devfs가 2.3.46 커널에 들어갔을 당시, 나는 수많은 보고를 받았다. 대부분의 보고들은 사람들이 devfsd 없이 운영했기 때문이었고, 그 중에 어떤 것들이 깨졌다(사용할 수 없는 시스템이 되었다). 나는 순간적인 설정잘못으로 인한 버그보다 실제 버그에 전념하기를 원한다. 만약 다른 코드(예를 들어 glibc, X server)에서 버그/오류를 수정해야 한다고 느낀다면, 그 메인테이너들에게 확인하라. 그들은 (나보다) 훌륭하게 해결할 것이다.
devfs의 커널패치는 합리적인 디바이스 트리를 생성한다. 위에 기술된대로, 만약 예전 방식의 /dev 네이밍 스키마를 유지하기 원한다면, 적당하게(맨 페이지에서 보는대로) devfsd를 설정하면 된다. 예전 방식을 선호하는 사람들은 이번 섹션을 건너뛰어라. 체계화된 이름과 명확한 /dev를 좋아하는 사람들은 읽어보길 바란다.
만약 devfsd를 실행하지 않았다면, 호환 엔트리의 관리를 할수 없고, 새로운 이름을 사용하기 위해서는 당신의 시스템을 설정해야 할 것이다. 예를 들어, 새로운 디스크의 네이밍 스키마를 사용하기 위해서 /etc/fstab를 수정해야 할 것이다. 만약 devfs를 사용하지 않는 커널을 부팅하시기 원한다면, devfs없이 커널을 부팅했을때를 위하여 예전 방식의 이름으로 돌아갈 disc-based /dev에 기초한 호환 심링크가 필요할 것이다.
당신은 호환엔트리를 유지할 디바이스를 선택할 수 있다. 예를 들어, BSD pseudo-terminal 디바이스에 대한 호환 엔트리를 원할 수도 있다(그렇지 않으면 C 라이브러리를 패치하거나, 대신에 Unix98 ptys를 사용해야 할 것이다). 이것은 /dev/devfsd.conf 에 정확한 정규표현식을 넣으면 되는 일이다.
당신이 선호하는 다른 네이밍 스키마를 선택할 수 있다. 예를 들어, 나는 너무 수직적이기 때문에 커널 제공 이름를 사용하지 않는다. 일반적인 잘못된 생각은 커널이 제공하는 이름들은 설정파일에 직접적으로 사용되어야 한다는 것이다. 이것은 그런게 아니다. 그것들은 장착된 디바이스들의 레이아웃을 반영하고 쉽게 분류하기 위하여 디자인된 것이다.
만약 커널이 제공하는 이름을 좋아한다면, 그것으로 좋다. 만약 그렇지 않다면, 당신이 좀더 선호하는 네임스페이스를 생성하기 위하여 devfsd를 사용해야 할 것이다. devfsd는 논리적이고 관리하기 쉽도록 하는 네임스페이스를 생성하기 위한 코드를 포함하고 있다. 근본적으로는, 커널이 제공하는 네임스페이스의 생략형을 생성한다.
당신은 자신만의 네임스페이스를 만들기 위한 과정에 있다. devfsd는 당신이 이 일을 쉽게 하도록 하는데 필요한 모든 기반을 가지고 있다. 필요한 일은 스크립트를 만드는 것이다. 심지어 c 코드를 작성할 수도 있으며 devfsd는 호출가능한 확장으로 그 공유 오브젝트를 적재할 수 있다.
주의를 기울여야 할 다른 점은 init프로그램이 /dev/telinit 유닉스 소켓을 생성하는지에 대한 것이다. init의 어떤 버전은 /dev/telinit를 생성하고 telinit프로그램은 init 프로세스와 통신한다. 만약 이런 시스템을 가지고 있다면, init 가 시작되기 전에 devfs가 /dev에 마운트되도록 해야 한다. 다른 말로 하면, init후에 수행되는 /etc/rc에는 devfs를 마운트 하도록 넣어서는 안된다. init의 다른 버전들은 init가 시작하기 전에 존재해야만 하는 named pipe /dev/initctl 가 필요하다. 다시말하지만 init가 시작되기 전에 그 named pipe를 생성하고 devfs를 마운트해야 한다.
기본적인 행동은 2.3.x 이후의 커널이 부팅할때에는 /dev 에 devfs를 마운트 하지 않는 것이다. 이것은 부팅 옵션에 "devfs=mount"를 넣음으로써 고칠 수 있다. 이 문제는 init의 문제를 해결하고, 다음의 끔찍한 상황(Cannot open initial console 메세지)을 막아준다. devfs 패치가 적용되어야 하는 2.2.x의 커널에서는 기본적으로 마운트 한다.
만약 /dev에 devfs를 자동으로 마운트한다면, 부트 스크립트에서 /dev/initctl를 생성하도록 해야 한다. 다음의 줄을 추가하라:
다른 방법으로는, 커널이 /dev에 devfs를 마운트 하기를 원치 않는다면, /dev/initctl문제를 해결하기 위하여 다음의 프로시져를 사용할 수 수 있다:
init의 최신 버전은 /dev/initctl를 자동으로 생성하므로, 이것에 대해서 걱정할 필요가 없다는 것을 기억하라.
모듈의 자동로딩을 하기 위해서는 devfsd를 설정할 필요가 있다. 다음의 줄을 /etc/devfsd.conf파일에 추가시켜라:
devfsd-v1.3.10 이후로, MODLOAD 에 의해 사용되는 포괄적인 /etc/modules.devfs 설정 파일이 설치된다. 이것은 대부분의 설정들에 대해 충분하다. 만약 설정이 더 필요하다면, /etc/modules.conf파일을 수정하라. devfs가 모듈의 자동로딩을 하는 방법은 :
프로세스가 디바이스 노드의 탐색시도를 한다(e.g. /dev/fred)
만약 디바이스 노드가 존재하지 않으면, 전체경로가 문자열로 devfsd에 넘겨진다.
devfsd는 modprobe 프로그램(위에서 보여진 설정 라인이 존재하는) 에 그 문자열을 전해주고, 그 설정파일인 /etc/modules.devfs에 명시한다.
/etc/modules.devfs는 로컬 설정에 접근하기 위해 /etc/modules.conf을 포함한다.
modprobe는 그 경로를 모듈이름으로 변환하는 앨리어스를 탐색함으로써 그것의 설정파일을 찾을 것이다.
변환된 경로는 그 모듈을 로딩하는데 사용된다.
만약 mymod모듈을 로딩하기 위하여 /dev/fred를 탐색하기 원한다면, /etc/modules.conf에 다음의 줄을 추가하라:
그 /etc/modules.devfs 서정 파일은 표준 디바이스 이름에 대해서 각각의 앨리어스를 제공한다. 만약 이 파일을 자세하게 찾는다면, 어떤 모듈은 여러개의 앨리어스 설정 줄이 필요하다는 것을 알것이다. 그것은 엣 방시과 새로운 방식의 디바이스 이름에 대해 모듈 자동로딩을 지원하기 위해 필요하다.
만약 "devfs=only" 부트 옵션을 설정했을때 devfs 디바이스가 root를 마운트 하기를 원한다면, 부팅시 커널옵션에 "root=<device>" 옵션을 넣어야 한다. LILO를 사용한다면, lilo.conf에 이것을 가지고 있어야만 한다:
놀라운가? 옙, 나 역시 그렇다. 다음의 줄을 당신이 가지고 있다면 (대부분의 사람들이 그런 것처럼) 해결한다:
LILO는 <device>의 디바이스 번호를 결정할 것이고, 그 커널을 시작하게 전에 커널 이미지의 특정 부분에 그 번호를 기록할 것이며, 그 커널은 루트 파일시스템을 마운트 하기 위하여 그 디바이스 번호를 사용할 것이다. 그래서, "append" 변수를 사용하는 것은 LILO가 그 루트 파일시스템을 devfs가 사용할 수 있는 문자열로 넘겨 주도록 확실히 하는 것이다.
만약 "devfs=only"를 사용하지 않는다면 신경쓸 것 없다.
C 라이브러리의 어떤 버전에서는 ttyname(3)가 심볼릭 링크인 디바이스 엔트리에 대해서는 오류를 만들어낸다. tty(1) 프로그램은 이 함수에 의존한다. 나는 이것을 수정하기 위하여 libc 5.4.43에 패치를 만들었다. 이것은 libc 5.4.44에 포함되어 있고 비슷핸 패치가 glibc 2.1.4에 있다.
커널은 기본 네이밍 스키마를 제공한다. 이 스키마는 특정한 디바이스나 디바이스 형태에 따라 검색하고, 사용가능한 디바이스를 찾아보는데 쉽도록 디자인 된다. 어떤 디바이스 형태(하드 디스크 같은)는 그런 부류의 디바이스가 사용가능한가를 알아보기 쉽게 하기 위해 그 항목의 디렉토리를 가지고 있다. 종종, 그 항목들은 사용가능한 디바이스의 구조를 반영하기 위한 디렉토리 트리에 심볼릭 링크로 되어 있다. 기하학적인 트리는 당신의 디바이스가 어떻게 배열되어 있는지 보는데 유용하다.
아래는 대부분의 일반적인 드라이버들에 대한 네이밍 스키마의 목록이다. 예약된 디바이스 이름들의 목록은 참고가 가능하다. 그 목록에 추가되기 원한다면 rgooch (at) atnf.csiro.au 에 메일을 보내라. 다른 이름들도 그 메인테이너의 판단에 따라 요청된 이름대신 할당될 수 있다.
SCSI, IDE 또는 무엇이라도, 모든 디스크는 /dev/discs 아래에 위치한다.
이들 각 항목들마다 그 디바이스에 대하여 디렉토리에 심볼릭 링크가 걸려있다. 디바이스 디렉토리는 다음을 포함한다.
SCSI, IDE 또는 어떤 CD-ROM이던지간에 모든 CD-ROM들은 /dev/cdroms 계열아래 존재한다.:
이들 항목 각각은 그 디바이스에 대한 실제 디바이스 항목에 대한 심볼릭 링크이다.
SCSI, IDE 를 막론하고 모든 테잎 장치들은 /dev/tapes계열아래에 위치한다.
이들 항목 각각은 그 디바이스에 대한 디렉토리의 심볼릭 링크이다.
어떤 SCSI 디바이스를 유일하게 판별하기 위해서는 다음의 정보가 필요하다:
모든 SCSI 디바이스는 /dev/scsi (devfs가 /dev에 마운트 되었다는 전제하에) 아래 위치한다. 그러므로, 다음 파라미터:c=1, b=2, t=3, u=4 를 가지는 SCSI 디바이스는 다음과 같이 나타날 것이다.
이 디렉토리 안에서 SCSI 디바이스 타잎 드라이버가 인스톨된 것에 의존하여 디바이스 항목 번호가 만들어질 것이다.
SCSI 디스크 드라이버가 만드는 항목을 알기위해서는 디스크 네이밍 체계에 대한 섹션을 보라.
SCSI 테잎 드라이버 항목이 만들어지는 것에 대해 알고 싶으면 테잎 네이밍 쳬게에 대한 섹션을 보라.
SCSI generic 드라이버는 다음을 만든다:
IDE 디바이스를 유일하게 지정하기 위해서는 다음의 정보가 필요하다:
모든 IDE 디바이스들은 /dev/ide아레 위치하고, SCSI 서브시스템과 비슷한 네이밍 체계를 사용한다.
모든 XT 디스크들은 /dev/xd아래 위치한다. 첫번째 XT 디스크는 /dev/xd/disc0디렉토리를 가진다.
New name Old-name Device Type --------- -------- ----------- /dev/tts/{0,1,...} /dev/ttyS{0,1,...} Serial ports /dev/cua/{0,1,...} /dev/cua{0,1,...} Call out devices /dev/vc/0 /dev/tty Current virtual console /dev/vc/{1,2,...} /dev/tty{1...63} Virtual consoles /dev/vcc/{0,1,...} /dev/vcs{1...63} Virtual consoles /dev/pty/m{0,1,...} /dev/ptyp?? PTY masters /dev/pty/s{0,1,...} /dev/ttyp?? PTY slaves
플로피 디스크들은 /dev/floppy디렉토리에 위치한다.
Loop 디바이스들은 /dev/loop디렉토리에 위치한다.
Sound 디바이스들은 /dev/sound디렉토리에 위치한다. (audio, sequencer,...).
Devfsd는 커널제공 네임스페이스 의 편리한 축약형인 네이밍 스키마를 제공한다. 어떤 경우에는, 커널이 제공하는 네이밍 스키마는 매우 편리하고, 따라서 devfsd는 다른 네이밍 스키마를 제공하지 않는다. devfsd가 만드는 편리한 이름은 실제로 오리지날 devfs 커널 패치가 만드는 이름과 동일하다(리누즈가 Big Name Change를 지시하기 전까지). 이것들은 "새로운 호환 엔트리"로서 참고된다.
이들 편리한 이름을 생성하기 위해 devfsd를 설정하기 위하여, 다음의 줄이 /etc/devfsd.conf에 추가되어야 한다:
이것은 커널이 제공하는 이름을 지정하기 위하여 devfsd가 심볼릭 링크를 만들(없앨)도록 한다.
모든 SCSI 디스크들은 /dev/sd아래에 위치한다 (devfs는 /dev에 마운트되었다고 가정하면). 그러므로, 다음의 파라미터:c=1,b=2,t=3,u=4를 가지는 SCSI 디스크들은
에 나타난다.
모든 SCSI 테입들은 /dev/st아래 위치한다. SCSI 디스크들과 유사한 네이밍 체계가 사용된다. 다음과 같은 파라미터 : c=1, b=2, t=3, u=4 를 가지는 SCSI 테잎들은 다음과 같이 나타난다:
모든 SCSI CD-ROM들은 /dev/sr아래 위치한다. SCSI 디스크들과 비슷한 네이밍 체계를 사용한다. 다음과 같은 파라미터: c=1, b=2, t=3, u=4 를 가지는 SCSI CD-ROM은 다음과 같이 나타난다:
모든 SCSI CD-ROM들은 /dev/sg아래 위치한다. SCSI 디스크와 비슷한 네이밍 체계를 사용한다. 다음과 같은 파라미터: c=1, b=2, t=3, u=4 를 가지는 SCSI generic 디바이스는 다음과 같이 나타난다:
모든 IDE 디스크들은 SCSI 디스크들과 비슷한 방법을 사용하여, /dev/ide/hd아래 위치한다. 다음의 맵핑이 새로운 이름과 예전 이름 사이에 존재한다.
IDE 디스크들과 유사한 네이밍 체계가 사용된다. 그 항목은 /dev/ide/mt디렉토리 안에서 나타날 것이다.
IDE 디스크와 비슷한 네이밍 체계가 사용된다. 각 항목은 /dev/ide/cd디렉토리 안에서 나타날 것이다.
IDE 디스크와 비슷한 네이밍 체계를 사용한다. 각 항목은 /dev/ide/fd디렉토리 안에서 나타날 것이다.
모든 XT 디스크들은 /dev/xd아래에 위치한다. 첫번째 XT 디스크는 /dev/xd/c0t0처럼 나타날 것이다.
에전의 호환이름들은 /dev/hda, /dev/sda, /dev/rtc 등등의 예전부터 유지되어온 디바이스 이름을 사용한다. Devfsd는 오래된 이름을 계속 사용할 수 있도록 호환 심링크를 생성하도록 설정파일에 설정될 수 있고, 따라서 오래된 응용프로그램들은 계속하여 잘 작동하게 될 것이다.
devfsd가 이런 예전의 이름을 생성하도록 설정하기 위해서 다음의 줄이 /etc/devfsd.conf에 추가되어야 한다
이것은 devfsd가 커널이 제공하는 이름을 지정하도록 하는 심볼릭 링크를 만들(없애)도록 한다.
Devfs는 SCSI 호스트 번호에 대해 기초한 SCSI 디스크를 식별하도록 허용한다. 만약 당신의 컴퓨터에 오직 하나의 SCSI 호스트(card)가 있다면, 호스트 번호는 0을 받게 될 것이다. 당신이 여러개의 SCSI 호스트를 가지고 있다면 그다지 쉽지 않다. 불행하게도, 때때로 SCSI 호스트의 번호를 얻기 원하는 것을 추측하는데 어려움이 있을 수 있다. 이것을 쉽게 하기 위해서, "scsihosts"라 불리는 커널 부트 파라미터가 있다. 이것은 SCSI 호스트들의 다른 타입에 대해 순서를 결정하도록 해준다. 이 파라미터의 문법은:
이다. 여기서 <name_1>,<name_2>,...,<name_n> 들은 /proc 파일시스템에서 사용된 드라이버들의 이름들이다. 예를 들어:
는
에 연결된 디바이스를 의미한다. 원한다면 분리자로 ':' 대신에 ','를 사용할 수 있다. 나는 여기서 devfsd 네이밍 스키마 를 사용한다.
- 첫번째 aha1542 컨트롤러 - /dev/scsi/host0/bus#/target#/lun# 일 것이다. - 첫번째 병렬포트 ZIP - /dev/scsi/host1/bus#/target#/lun# 일 것이다. - 두번째 aha1542 컨트롤러 - /dev/scsi/host2/bus#/target#/lun# 일 것이다. - 첫번째 NCR53C7xx 컨트롤러 - /dev/scsi/host4/bus#/target#/lun# 일 것이다. - 나머지 컨트롤러 - /dev/scsi/host5/bus#/target#/lun#, /dev/scsi/host6/bus#/target#/lun# 등등 일 것이다. - 만약 위의 어떤 컨트롤러도 발견되지 않았다면 - 그 예약된 이름들이 다른 디바이스에 의해 사용되지 않는다는 것이다. - /dev/scsi/host3/bus#/target#/lun# 는 절대로 사용되지 않는다.
만약 같은 타입으로 여러개의 카드(NCR53c8xx와 같은)를 가지고 있다면, 이 스키마가 SCSI 호스트를 지정하지는 못한다. 이런 경우에 당신은 이것을 제어하기 위해서 드라이버를 지정하는 부트 파라미터를 사용할 필요가 있다.