readme

上传linux-jx2410的源代码

Alternatively, you can have devfs choose unique device numbers for
you. When you register a character or block device using
devfs_register you can provide the optional
DEVFS_FL_AUTO_DEVNUM flag, which will then automatically allocate a
unique device number (the allocation is separated for the character
and block devices).

This device number is a 16 bit number, so this leaves plenty of space
for large numbers of discs and partitions. This scheme can also be
used for character devices, in particular the tty devices, which are
currently limited to 256 pseudo-ttys (this limits the total number of
simultaneous xterms and remote logins).  Note that the device number
is limited to the range 36864-61439 (majors 144-239), in order to
avoid any possible conflicts with existing official allocations.

Please note that using dynamically allocated block device numbers may
break the NFS daemons (both user and kernel mode), which expect dev_t
for 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 of
device numbers, there are no compatibility issues with userspace.

-----------------------------------------------------------------------------


Questions and Answers


Making things work
Alternatives to devfs
What I don't like about devfs
How to report bugs
Strange kernel messages
Compilation problems with devfsd



Making things work

Here are some common questions and answers.



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.





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 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:



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


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


if you get an Oops, run ksymoops to decode it so that the
names of the offending functions are provided. A non-decoded Oops is
pretty useless


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 do about them, if
anything).



devfs_register(fred): could not append to parent, err: -17

You need to check what the error code means, but usually 17 means
EEXIST. This means that a driver attempted to create an entry
fred in a directory, bu