readme

linux-2.6.15.6

Devfsd is not managing all my permissions

Make 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 events

See the previous entry: you may need to capture CREATE events.


X will not start

Make 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 separate
namespace. They are accessed via socket(2) and
setsockopt(2) calls, and thus require no device nodes. I have
raised the possibilty of moving network devices into the device
namespace, 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, then
you know that devfs was compiled into your kernel. If you have
correctly configured and rebuilt your kernel, then devfs will be
built-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 you
don't know how to patch your kernel, use 2.4.x instead, don't bother
asking me how to patch)
Forgetting to set CONFIG_EXPERIMENTAL=y
Forgetting to set CONFIG_DEVFS_FS=y
Forgetting to set CONFIG_DEVFS_MOUNT=y (if you want devfs
to be automatically mounted at boot)
Editing your .config manually, instead of using make
config or make xconfig
Forgetting to run make dep; make clean after changing the
configuration and before compiling
Forgetting to compile your kernel and modules
Forgetting to install your kernel
Forgetting to install your modules

Please check twice that you've done all these steps before sending in
a 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. Even
if the daemon is not running, this entry will exist. Testing for the
existence of this entry is the approved method of determining if devfs
is mounted or not. Note that the type of entry (i.e. regular file,
character device, named pipe, etc.) may change without notice. Only
the 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 (see
above). Then you will either need to:

set CONFIG_DEVFS_MOUNT=y in your kernel config
pass devfs=mount to your boot loader
mount devfs manually in your boot scripts with:
mount -t none devfs /dev



Mount by volume LABEL=<label> doesn't work with
devfs

Most probably you are not mounting devfs onto /dev. What
happens is that if your kernel config has CONFIG_DEVFS_FS=y
then the contents of /proc/partitions will have the devfs
names (such as scsi/host0/bus0/target0/lun0/part1). The
contents of /proc/partitions are used by mount(8) when
mounting by volume label. If devfs is not mounted on /dev,
then mount(8) will fail to find devices. The solution is to
make sure that devfs is mounted on /dev. See above for how to
do that.


I have extra or incorrect entries in /dev

You may have stale entries in your dev-state area. Check for a
RESTORE configuration line in your devfsd configuration
(typically /etc/devfsd.conf). If you have this line, check
the contents of the specified directory for stale entries. Remove
any entries which are incorrect, then reboot.


I get "Unable to open initial console" messages at boot

This 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 devfs

I've attempted to collate all the anti-devfs proposals and explain
their 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 devices
can register create and remove events, and a daemon listens for those
events. The daemon would then populate/depopulate /dev (which
resides on disc).

This has several limitations:


it only works for modules loaded and unloaded (or devices inserted
and removed) after the kernel has finished booting. Without a database
of events, there is no way the daemon could fully populate
/dev


if you add a database to this scheme, the question is then how to
present that database to user-space. If you make it a list of strings
with embedded event codes which are passed through a pipe to the
daemon, then this is only of use to the daemon. I would argue that the
natural way to present this data is via a filesystem (since many of
the events will be of a hierarchical nature), such as devfs.
Presenting the data as a filesystem makes it easy for the user to see
what is available and also makes it easy to write scripts to scan the
"database"


the tight binding between device nodes and drivers is no longer
possible (requiring the otherwise perfectly avoidable
table lookups)


you cannot catch inode lookup events on /dev which means
that module autoloading requires device nodes to be created. This is a
problem, particularly for drivers where only a few inodes are created
from a potentially large set


this technique can't be used when the root FS is mounted
read-only




Just implement a better scsidev

This suggestion involves taking the scsidev programme and
extending it to scan for all devices, not just SCSI devices. The
scsidev programme works by scanning /proc/scsi

Problems:


the kernel does not currently provide a list of all devices
available. Not all drivers register entries in /proc or
generate kernel messages


there is no uniform mechanism to register devices other than the
devfs API


implementing such an API is then the same as the
proposal above




Put /dev on a ramdisc

This suggestion involves creating a ramdisc and populating it with
device nodes and then mounting it over /dev.

Problems:



this doesn't help when mounting the root filesystem, since you
still need a device node to do that


if you want to use this technique for the root device node as
well, you need to use initrd. This complicates the booting sequence
and makes it significantly harder to administer and configure. The
initrd is essentially opaque, robbing the system administrator of easy
configuration


insufficient information is available to correctly populate the
ramdisc. So we come back to the
proposal above to "solve" this


a ramdisc-based solution would take more kernel memory, since the
backing store would be (at best) normal VFS inodes and dentries, which
take 284 bytes and 112 bytes, respectively, for each entry. Compare
that to 72 bytes for devfs




Do nothing: there's no problem

Sometimes people can be heard to claim that the existing scheme is
fine. This is what they're ignoring:


device number size (8 bits each for major and minor) is a real
limitation, and must be fixed somehow. Systems with large numbers of
SCSI devices, for example, will continue to consume the remaining
unallocated major numbers. USB will also need to push beyond the 8 bit
minor limitation


simply increasing the device number size is insufficient. Apart
from causing a lot of pain, it doesn't solve the management issues
of a /dev with thousands or more device nodes


ignoring the problem of a huge /dev will not make it go
away, and dismisses the legitimacy of a large number of people who
want a dynamic /dev


the standard response then becomes: "write a device management
daemon", which brings us back to the
proposal above




What I don't like about devfs

Here are some common complaints about devfs, and some suggestions and
solutions that may make it more palatable for you. I can't please
everybody, but I do try :-)

I hate the naming scheme

First, remember that no naming scheme will please everybody. You hate
the 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 what
exists now is a combination of the choices made by the
devfs author and the
kernel maintainer (Linus).

However, not all is lost. If you want to create your own naming
scheme, it is a simple matter to write a standalone script, hack
devfsd, or write a script called by devfsd. You can create whatever
naming scheme you like.

Further, if you want to remove all traces of the devfs naming scheme
from /dev, you can mount devfs elsewhere (say
/devfs) and populate /dev with links into
/devfs. This population can be automated using devfsd if you
wish.

You can even use the VFS binding facility to make the links, rather
than using symbolic links. This way, you don't even have to see the
"destination" of these symbolic links.

Devfs puts policy into the kernel

There's already policy in the kernel. Device numbers are in fact
policy (why should the kernel dictate what device numbers I use?).
Face it, some policy has to be in the kernel. The real difference
between device names as policy and device numbers as policy is that
no one will use device numbers directly, because device
numbers are devoid of meaning to humans and are ugly. At least with
the devfs device names, (even though you can add your own naming
scheme) some people will use the devfs-supplied names directly. This
offends some people :-)

Devfs is bloatware

This is not even remotely true. As shown above,
both code and data size are quite modest.


How to report bugs

If you have (or think you have) a bug with devfs, please follow the
steps below:



make sure you have enabled debugging output when configuring your
kernel. You will need to set (at least) the following config options:

CONFIG_DEVFS_DEBUG=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SLAB=y



please make sure you have the latest devfs patches applied. The
latest kernel version might not have the latest devfs patches applied
yet (Linus is very busy)


save a copy of your complete kernel logs (preferably by
using the dmesg programme) for later inclusion in your bug
report. You may need to use the -s switch to increase the
internal buffer size so you can capture all the boot messages.
Don't edit or trim the dmesg output




try booting with devfs=dall passed to the kernel boot
command line (read the documentation on your bootloader on how to do
this), and save the result to a file. This may be quite verbose, and
it may overflow the messages buffer, but try to get as much of it as
you can


send a copy of your devfsd configuration file(s)

send the bug report to me first.
Don't expect that I will see it if you post it to the linux-kernel
mailing list. Include all the information listed above, plus
anything else that you think might be relevant. Put the string
devfs somewhere in the subject line, so my mail filters mark
it as urgent




Here is a general guide on how to ask questions in a way that greatly
improves your chances of getting a reply:

http://www.tuxedo.org/~esr/faqs/smart-questions.html. If you have
a bug to report, you should also read

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html.


Strange kernel messages

You may see devfs-related messages in your kernel logs. Below are some
messages and what they mean (and what you should d