devfs에 기초한 /dev 안에서 각 엔트리(디바이스노드)에 대해 드라이버는 devfs_register()를 호출해야만 한다. 이것은 내부 테이블에 디바이스 엠트리의 이름과 file_operation 구조체 포인터와 약간의 다른 것들을 추가한다. 디바이스 엔트리는 어떤 때라도 추가되거나 제거될 수 있을 것이다. 디바이스 엔트리가 등록되면, devfs가 마운트된 곳에 자동으로 나타난다.
엔트리에 대한 탐색이 수행되고 만약 그 엔트리에 대한 어떠한 드라이버 정보도 없을때 devfs는 devfsd의 호출을 시도한다. 만약 어떠한 정보도 찾아지지 않는다면, negative dentry가 얻어지고, 다음 단계의 수행은 VFS(create() 또는 mknod() 함수처럼 inode 를 조작하는 메쏘드 와 같은)에 의해 호출될 것이다. 드라이버의 정보가 찾아지면 inode는 생성될 것이고(미리 존재하는 것이 없다면) 그것으로 잘 될 것이다.
mknod() 메쏘드는 사용자에게 devfs 안에 고유하게 이름붙여진 파이프를 만들도록 허용하거나, 이미 존재하지 않는다면 블럭 스페셜 inode를 만들수 있도록 허용한다. 사용자는 사용자 스스로 퍼미션과 소유권을 설정할 수 있는 캐릭터나 블럭 스페셜 inode를 생성하기를 원할 수도 있다. 나중에, 만약 디바이스 드라이버가 같은 이름으로 엔트리를 등록한다면, 그 퍼미션과 소유권과 시간은 계속 유지된다. 이것은 그 드라이버가 적재되기 전이라도 디바이스에 대한 보호권을 설정할 수 있도록 한다. 한번이라도 inode를 만들었다면 디렉토리에 나타난다.
디바이스 드라이버는 엔트리를 등록해제하기 위해서 devfs_unregister()를호출한다.
2.2.x대의 커널들
inode 생성의 의미는 devfs가 "특별한" 옵션과 함께 마운트 되었을때는 다르다. 지금, 디바이스 엔트리가 등록되었을때, 그 디바시으를 생성하기 위해 mknod() 를 사용하기 전까지는 나타나지 않을 것이다. mknod()가 devfs_register() 를 사용하여 그 디바이스가 되기 전이던 중요하지 않다. 이런 작업의 목적은 당신이 그 제한안에 최소한의 devfs를 마운트 하기 원하는 곳에서 chroot(2)의 제한을 지원하는 것이다. 단지 당신이 특별히 사용가능하도록 설정하는(당신만의 mknod() 설정을 통하여) 디바이스만이 접근 가능하게 될 것이다.
2.4.x 대의 커널들
현재의 2.3.99 커널은 VFS가 전체 파일시스템의 네임스페이스의 한 부분을 그 네임스페이스의 다른 부분으로 리바인드 시킬수 있다. 이것은 심지어 leaf-node 레벨에서도 작동하며, 각각의 파일들과 디바이스 노드가 그 네임스페이스의 다른 부분으로 바인드 될수 있다는 것을 의미한다. 이것은 링크를 만드는 것과 유사하지만, 파일시스템(하드 링크와는 다른)과 chroot() 의 제한(심볼릭 링크와 다른)을 통하여 작동하기 때문에 더 낫다.
VFS에서의 이런 향상 덕분에, devfs에서 다중 마운트에 대한 기능은 더이상 필요하지 않다. 관리자는 VFS 바인딩을 사용하여 chroot(2) 제한 안에 최소한의 디바이스 트리를 만들게 된다. 이것은 devfs의 다중마운트 능력이 가진 대부분의 기능을 제공하기 때문에, 나는(저자는) 다중 마운트 코드를 (RFC 에서의 논의 후에) 빼버렸다. 이것은 코드크기의 감소와 간소함을 가져다 주었다.
만약 최소한의 chroot() 제한을 만들기 원한다면, 다음의 명령어를 치면 된다 :
보여주기 원하는 다른 디바이스 노드에도 반복하라. 간단하다!