an inode is on a different filesystem than another inode. The devicenumber used is the one for the block device which a filesystem isusing. To preserve compatibility with userspace programmes, blockdevices using devfs need to have unique device numbers allocated tothem. Furthermore, POSIX specifies device numbers, so some kind ofdevice number needs to be presented to userspace.The simplest option (especially when porting drivers to devfs) is tokeep using the old major and minor numbers. Devfs will take whatevervalues are given for major&minor and pass them onto userspace.This device number is a 16 bit number, so this leaves plenty of spacefor large numbers of discs and partitions. This scheme can also beused for character devices, in particular the tty devices, which arecurrently limited to 256 pseudo-ttys (this limits the total number ofsimultaneous xterms and remote logins).  Note that the device numberis limited to the range 36864-61439 (majors 144-239), in order toavoid any possible conflicts with existing official allocations.Please note that using dynamically allocated block device numbers maybreak the NFS daemons (both user and kernel mode), which expect dev_tfor a given device to be constant over the lifetime of remote mounts.A final note on this scheme: since it doesn't increase the size ofdevice numbers, there are no compatibility issues with userspace.-----------------------------------------------------------------------------Questions and AnswersMaking things workAlternatives to devfsWhat I don't like about devfsHow to report bugsStrange kernel messagesCompilation problems with devfsdMaking things workHere are some common questions and answers.Devfsd doesn't startMake sure you have compiled and installed devfsdMake sure devfsd is being started from your bootscriptsMake sure you have configured your kernel to enable devfs (seebelow)Make sure devfs is mounted (see below)Devfsd is not managing all my permissionsMake sure you are capturing the appropriate events. For example,device entries created by the kernel generate REGISTER events,but those created by devfsd generate CREATE events.Devfsd is not capturing all REGISTER eventsSee the previous entry: you may need to capture CREATE events.X will not startMake sure you followed the steps outlined above.Why don't my network devices appear in devfs?This is not a bug. Network devices have their own, completely separatenamespace. They are accessed via socket(2) andsetsockopt(2) calls, and thus require no device nodes. I haveraised the possibilty of moving network devices into the devicenamespace, but have had no response.How can I test if I have devfs compiled into my kernel?All filesystems built-in or currently loaded are listed in/proc/filesystems. If you see a devfs entry, thenyou know that devfs was compiled into your kernel. If you havecorrectly configured and rebuilt your kernel, then devfs will bebuilt-in. If you think you've configured it in, but/proc/filesystems doesn't show it, you've made a mistake.Common mistakes include:Using a 2.2.x kernel without applying the devfs patch (if youdon't know how to patch your kernel, use 2.4.x instead, don't botherasking me how to patch)Forgetting to set CONFIG_EXPERIMENTAL=yForgetting to set CONFIG_DEVFS_FS=yForgetting to set CONFIG_DEVFS_MOUNT=y (if you want devfsto be automatically mounted at boot)Editing your .config manually, instead of using makeconfig or make xconfigForgetting to run make dep; make clean after changing theconfiguration and before compilingForgetting to compile your kernel and modulesForgetting to install your kernelForgetting to install your modulesPlease check twice that you've done all these steps before sending ina bug report.How can I test if devfs is mounted on /dev?The device filesystem will always create an entry called".devfsd", which is used to communicate with the daemon. Evenif the daemon is not running, this entry will exist. Testing for theexistence of this entry is the approved method of determining if devfsis mounted or not. Note that the type of entry (i.e. regular file,character device, named pipe, etc.) may change without notice. Onlythe existence of the entry should be relied upon.When I start devfsd, I see the error:Error opening file: ".devfsd"   No such file or directory?This means that devfs is not mounted. Make sure you have devfs mounted.How do I mount devfs?First make sure you have devfs compiled into your kernel (seeabove). Then you will either need to:set CONFIG_DEVFS_MOUNT=y in your kernel configpass devfs=mount to your boot loadermount devfs manually in your boot scripts with:mount -t none devfs /devMount by volume LABEL=<label> doesn't work withdevfsMost probably you are not mounting devfs onto /dev. Whathappens is that if your kernel config has CONFIG_DEVFS_FS=ythen the contents of /proc/partitions will have the devfsnames (such as scsi/host0/bus0/target0/lun0/part1). Thecontents of /proc/partitions are used by mount(8) whenmounting by volume label. If devfs is not mounted on /dev,then mount(8) will fail to find devices. The solution is tomake sure that devfs is mounted on /dev. See above for how todo that.I have extra or incorrect entries in /devYou may have stale entries in your dev-state area. Check for aRESTORE configuration line in your devfsd configuration(typically /etc/devfsd.conf). If you have this line, checkthe contents of the specified directory for stale entries. Removeany entries which are incorrect, then reboot.I get "Unable to open initial console" messages at bootThis usually happens when you don't have devfs automounted onto/dev at boot time, and there is no valid/dev/console entry on your root file-system. Create a valid/dev/console device node.Alternatives to devfsI've attempted to collate all the anti-devfs proposals and explaintheir limitations. Under construction.Why not just pass device create/remove events to a daemon?Here the suggestion is to develop an API in the kernel so that devicescan register create and remove events, and a daemon listens for thoseevents. The daemon would then populate/depopulate /dev (whichresides on disc).This has several limitations:it only works for modules loaded and unloaded (or devices insertedand removed) after the kernel has finished booting. Without a databaseof events, there is no way the daemon could fully populate/devif you add a database to this scheme, the question is then how topresent that database to user-space. If you make it a list of stringswith embedded event codes which are passed through a pipe to thedaemon, then this is only of use to the daemon. I would argue that thenatural way to present this data is via a filesystem (since many ofthe events will be of a hierarchical nature), such as devfs.Presenting the data as a filesystem makes it easy for the user to seewhat is available and also makes it easy to write scripts to scan the"database"the tight binding between device nodes and drivers is no longerpossible (requiring the otherwise perfectly avoidabletable lookups)you cannot catch inode lookup events on /dev which meansthat module autoloading requires device nodes to be created. This is aproblem, particularly for drivers where only a few inodes are createdfrom a potentially large setthis technique can't be used when the root FS is mountedread-onlyJust implement a better scsidevThis suggestion involves taking the scsidev programme andextending it to scan for all devices, not just SCSI devices. Thescsidev programme works by scanning /proc/scsiProblems:the kernel does not currently provide a list of all devicesavailable. Not all drivers register entries in /proc orgenerate kernel messagesthere is no uniform mechanism to register devices other than thedevfs APIimplementing such an API is then the same as theproposal abovePut /dev on a ramdiscThis suggestion involves creating a ramdisc and populating it withdevice nodes and then mounting it over /dev.Problems:this doesn't help when mounting the root filesystem, since youstill need a device node to do thatif you want to use this technique for the root device node aswell, you need to use initrd. This complicates the booting sequenceand makes it significantly harder to administer and configure. Theinitrd is essentially opaque, robbing the system administrator of easyconfigurationinsufficient information is available to correctly populate theramdisc. So we come back to theproposal above to "solve" thisa ramdisc-based solution would take more kernel memory, since thebacking store would be (at best) normal VFS inodes and dentries, whichtake 284 bytes and 112 bytes, respectively, for each entry. Comparethat to 72 bytes for devfsDo nothing: there's no problemSometimes people can be heard to claim that the existing scheme isfine. This is what they're ignoring:device number size (8 bits each for major and minor) is a reallimitation, and must be fixed somehow. Systems with large numbers ofSCSI devices, for example, will continue to consume the remainingunallocated major numbers. USB will also need to push beyond the 8 bitminor limitationsimply increasing the device number size is insufficient. Apartfrom causing a lot of pain, it doesn't solve the management issuesof a /dev with thousands or more device nodesignoring the problem of a huge /dev will not make it goaway, and dismisses the legitimacy of a large number of people whowant a dynamic /devthe standard response then becomes: "write a device managementdaemon", which brings us back to theproposal aboveWhat I don't like about devfsHere are some common complaints about devfs, and some suggestions andsolutions that may make it more palatable for you. I can't pleaseeverybody, but I do try :-)I hate the naming schemeFirst, remember that no naming scheme will please everybody. You hatethe scheme, others love it. Who's to say who's right and who's wrong?Ultimately, the person who writes the code gets to choose, and whatexists now is a combination of the choices made by thedevfs author and thekernel maintainer (Linus).However, not all is lost. If you want to create your own namingscheme, it is a simple matter to write a standalone script, hackdevfsd, or write a script called by devfsd. You can create whatevernaming scheme you like.Further, if you want to remove all traces of the devfs naming schemefrom /dev, you can mount devfs elsewhere (say/devfs) and populate /dev with links into/devfs. This population can be automated using devfsd if youwish.You can even use the VFS binding facility to make the links, ratherthan using symbolic links. This way, you don't even have to see the"destination" of these symbolic links.Devfs puts policy into the kernelThere's already policy in the kernel. Device numbers are in factpolicy (why should the kernel dictate what device numbers I use?).Face it, some policy has to be in the kernel. The real differencebetween device names as policy and device numbers as policy is thatno one will use device numbers directly, because devicenumbers are devoid of meaning to humans and are ugly. At least withthe devfs device names, (even though you can add your own namingscheme) some people will use the devfs-supplied names directly. Thisoffends some people :-)Devfs is bloatwareThis is not even remotely true. As shown above,both code and data size are quite modest.How