diff options
| author | Ralf Baechle <ralf@linux-mips.org> | 2000-05-12 21:05:59 +0000 |
|---|---|---|
| committer | Ralf Baechle <ralf@linux-mips.org> | 2000-05-12 21:05:59 +0000 |
| commit | ba2dacab305c598cd4c34a604f8e276bf5bab5ff (patch) | |
| tree | 78670a0139bf4d5ace617b29b7eba82bbc74d602 /Documentation | |
| parent | b77bf69998121e689c5e86cc5630d39a0a9ee6ca (diff) | |
Merge with Linux 2.3.99-pre7 and various other bits.
Diffstat (limited to 'Documentation')
21 files changed, 1387 insertions, 617 deletions
diff --git a/Documentation/Changes b/Documentation/Changes index f5c4d516f..586a6de07 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -787,9 +787,9 @@ ftp://metalab.unc.edu/pub/Linux/hardware/pciutils-2.1.5.tar.gz Powertweak ========== -The 0.1.2 release: -http://linux.powertweak.com/files/powertweak-0.1.2.tgz -ftp://atrey.karlin.mff.cuni.cz/pub/linux/pci/powertweak/powertweak-0.1.2.tgz +The 0.1.13 release: +http://linux.powertweak.com/files/powertweak-0.1.13.tgz +ftp://atrey.karlin.mff.cuni.cz/pub/linux/pci/powertweak/powertweak-0.1.13.tgz Xosview ======= diff --git a/Documentation/Configure.help b/Documentation/Configure.help index e7dfc2b76..bb21ec1a5 100644 --- a/Documentation/Configure.help +++ b/Documentation/Configure.help @@ -1830,7 +1830,7 @@ limit match support CONFIG_IP_NF_MATCH_LIMIT limit matching allows you to control the rate at which a rule can be matched: mainly useful in combination with the LOG target ("LOG - target support", below). + target support", below) and to avoid some Denial of Service attacks. If you want to compile it as a module, say M here and read Documentation/modules.txt. If unsure, say `N'. @@ -6686,6 +6686,14 @@ CONFIG_PPP_BSDCOMP Note that the BSD compression code will always be compiled as a module; it is called bsd_comp.o and will show up in the directory modules once you have said "make modules". If unsure, say N. + +PPP over Ethernet (EXPERIMENTAL) +CONFIG_PPPOE + Support for PPP over Ethernet. + + This driver requires a specially patched pppd daemon. The patch to + pppd, along with binaries of a patched pppd package can be found at: + http://www.math.uwaterloo.ca/~mostrows Wireless LAN (non-hamradio) CONFIG_NET_RADIO @@ -9850,7 +9858,7 @@ CONFIG_USB_MDC800 Say Y here if you want to connect this type of still camera to your computer's USB port. This driver can be used with gphoto 0.4.3 and higher (look at http://www.gphoto.org ). - To use it create a device node with "mknod /dev/mustek c 10 171" and + To use it create a device node with "mknod /dev/mustek c 180 32" and configure it in your software. This code is also available as a module ( = code which can be @@ -10314,6 +10322,15 @@ CONFIG_DEVFS_FS If unsure, say N. +Enable automatic mounting at boot +CONFIG_DEVFS_MOUNT + This option appears if you have CONFIG_DEVFS_FS enabled. Setting + this to 'Y' will make the kernel automatically mount devfs onto /dev + when the system is booted, before the init thread is started. + You can override this with the "devfs=nomount" boot option. + + If unsure, say N. + Debug devfs CONFIG_DEVFS_DEBUG If you say Y here, then the /dev file system code will generate @@ -10444,6 +10461,8 @@ CONFIG_NTFS_RW damaged. Also, make sure to run chkdsk from within Microsoft Windows NT after having performed any writes to a NTFS partition from Linux to detect any problems as early as possible. + Please note that write support is limited to Windows NT4 and + earlier versions. If unsure, say N. diff --git a/Documentation/filesystems/devfs/ChangeLog b/Documentation/filesystems/devfs/ChangeLog index 96a358602..5728384e6 100644 --- a/Documentation/filesystems/devfs/ChangeLog +++ b/Documentation/filesystems/devfs/ChangeLog @@ -1496,3 +1496,40 @@ Work sponsored by SGI - Don't kill existing block ops in <devfs_read_inode> - Restore auto-ownership for /dev/pty/m* +=============================================================================== +Changes for patch v163 + +Work sponsored by SGI + +- Don't create missing directories in <devfs_find_handle> + +- Removed Documentation/filesystems/devfs/mk-devlinks + +- Updated Documentation/filesystems/devfs/README +=============================================================================== +Changes for patch v164 + +Work sponsored by SGI + +- Fixed CONFIG_DEVFS breakage in drivers/char/serial.c introduced in + linux-2.3.99-pre6-7 +=============================================================================== +Changes for patch v165 + +Work sponsored by SGI + +- Ported to kernel 2.3.99-pre6 +=============================================================================== +Changes for patch v166 + +Work sponsored by SGI + +- Added CONFIG_DEVFS_MOUNT +=============================================================================== +Changes for patch v167 + +Work sponsored by SGI + +- Updated Documentation/filesystems/devfs/README + +- Updated sample modules.conf diff --git a/Documentation/filesystems/devfs/README b/Documentation/filesystems/devfs/README index b0633ef5f..c9b111b9b 100644 --- a/Documentation/filesystems/devfs/README +++ b/Documentation/filesystems/devfs/README @@ -1,50 +1,97 @@ -/* -*- auto-fill -*- */ +Devfs (Device File System) FAQ - Device File System (devfs) Overview - Richard Gooch <rgooch@atnf.csiro.au> +Linux Devfs (Device File System) FAQ +Richard Gooch +1-MAY-2000 - 3-MAR-2000 +----------------------------------------------------------------------------- +NOTE: the master copy of this document is available online at: -Conventions used in this document <section> -================================= - -Each section in this document will have the string "<section>" at the -right-hand side of the section title. Each subsection will have -"<subsection>" at the right-hand side. These strings are meant to make -it easier to search through the document. - -NOTE that the master copy of this document is available online at: -http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.txt +http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html +and looks much better than the text version distributed with the +kernel sources. There is also an optional daemon that may be used with devfs. You can find out more about it at: + http://www.atnf.csiro.au/~rgooch/linux/ -NEWFLASH: The official 2.3.46 kernel has included the devfs -patch. Future patches will be released which build on this. +NEWFLASH: The official 2.3.46 kernel has +included the devfs patch. Future patches will be released which +build on this. + +A mailing list is available which you may subscribe to. Send +email +to majordomo@oss.sgi.com with the following line in the +body of the message: +subscribe devfs +The list is archived at + +http://oss.sgi.com/projects/devfs/archive/. + +----------------------------------------------------------------------------- + +Contents + + +What is it? + +Why do it? + +Who else does it? + +How it works + +Operational issues (essential reading) + +Instructions for the impatient +Permissions persistence accross reboots +Dealing with drivers without devfs support +All the way with Devfs +Other Issues +Kernel Naming Scheme +Devfsd Naming Scheme +SCSI Host Probing Issues + + + +Device drivers currently ported + +Allocation of Device Numbers + +Questions and Answers + +Making things work +Alternatives to devfs + + +Other resources + +----------------------------------------------------------------------------- -What is it? <section> -=========== + +What is it? Devfs is an alternative to "real" character and block special devices on your root filesystem. Kernel device drivers can register devices by name rather than major and minor numbers. These devices will appear in -the devfs automatically, with whatever default ownership and -protection the driver specified. +devfs automatically, with whatever default ownership and +protection the driver specified. A daemon (devfsd) can be used to +override these defaults. -NOTE that devfs is entirely optional. If you prefer the old disc-based -device nodes, then simply leave CONFIG_DEVFS_FS=n (the default). In -this case, nothing will change. -ALSO NOTE that if you do enable devfs, the defaults are such that full -compatibility is maintained with the old devices names. +NOTE that devfs is entirely optional. If you prefer the old +disc-based device nodes, then simply leave CONFIG_DEVFS_FS=n (the +default). In this case, nothing will change. ALSO NOTE that if you do +enable devfs, the defaults are such that full compatibility is +maintained with the old devices names. There are two aspects to devfs: one is the underlying device namespace, which is a namespace just like any mounted filesystem. The other aspect is the filesystem code which provides a view of the -device namespace. The reason I make a distinction is because the devfs +device namespace. The reason I make a distinction is because devfs can be mounted many times, with each mount showing the same device namespace. Changes made are global to all mounted devfs filesystems. Also, because the devfs namespace exists without any devfs mounts, you @@ -52,13 +99,20 @@ can easily mount the root filesystem by referring to an entry in the devfs namespace. The cost of devfs is a small increase in kernel code size and memory -usage. On a typical machine, the cost is under 0.2 percent. On a -modest system with 64 MBytes of RAM, the cost is under 0.1 percent. -The accusations of "bloatware" levelled at devfs are not justified. +usage. About 7 pages of code (some of that in __init sections) and 49 +bytes for each entry in the namespace (93 bytes if you access the +inode). A modest system has only a couple of hundred device entries, +so this costs a few more pages. Compare this with the suggestion to +put /dev on a ramdisc. + +On a typical machine, the cost is under 0.2 percent. On a modest +system with 64 MBytes of RAM, the cost is under 0.1 percent. The +accusations of "bloatware" levelled at devfs are not justified. + +----------------------------------------------------------------------------- -Why do it? <section> -========== +Why do it? There are several problems that devfs addresses. Some of these problems are more serious than others (depending on your point of @@ -69,8 +123,21 @@ The choice is a patchwork of inefficient user space solutions, which are complex and likely to be fragile, or to use a simple and efficient devfs which is robust. -Major&minor allocation <subsection> ----------------------- +There have been many counter-proposals to devfs, all seeking to +provide some of the benefits without actually implementing devfs. So +far there has been an absence of code and no proposed alternative has +been able to provide all the features that devfs does. Further, +alternative proposals require far more complexity in user-space (and +still deliver less functionality than devfs). Some people have the +mantra of reducing "kernel bloat", but don't consider the effects on +user-space. + +A good solution limits the total complexity of kernel-space and +user-space. + + +Major&minor allocation + The existing scheme requires the allocation of major and minor device numbers for each and every device. This means that a central co-ordinating authority is required to issue these device numbers @@ -81,8 +148,8 @@ will naturally choose a device name which reflects the functionality of the device, there is far less potential for namespace conflict. Solving this requires a kernel change. -/dev management <subsection> ---------------- +/dev management + Because you currently access devices through device nodes, these must be created by the system administrator. For standard devices you can usually find a MAKEDEV programme which creates all these (hundreds!) @@ -95,20 +162,24 @@ in a MAKEDEV programme, if you want to look at it that way). This is duplication of information, which is not good practice. Solving this requires a kernel change. -/dev growth <subsection> ------------ +/dev growth + A typical /dev has over 1200 nodes! Most of these devices simply don't exist because the hardware is not available. A huge /dev increases the time to access devices (I'm just referring to the dentry lookup times and the time taken to read inodes off disc: the next subsection shows some more horrors). + An example of how big /dev can grow is if we consider SCSI devices: + host 6 bits (say up to 64 hosts on a really big machine) channel 4 bits (say up to 16 SCSI buses per host) id 4 bits lun 3 bits partition 6 bits TOTAL 23 bits + + This requires 8 Mega (1024*1024) inodes if we want to store all possible device nodes. Even if we scrap everything but id,partition and assume a single host adapter with a single SCSI bus and only one @@ -128,6 +199,7 @@ scanned the kernel logs and deleted /dev entries which are not available and created them when they were available. This programme would need to be run every time a new module was loaded, which would slow things down a lot. + There is an existing programme called scsidev which will automatically create device nodes for SCSI devices. It can do this by scanning files in /proc/scsi. Unfortunately, to extend this idea to other device @@ -138,14 +210,16 @@ you go to this much effort, you may as well use devfs itself (which also provides this information). Furthermore, such a system would likely be implemented in an ad-hoc fashion, as different drivers will provide their information in different ways. + Devfs is much cleaner, because it (natually) has a uniform mechanism to provide this information: the device nodes themselves! -Node to driver file_operations translation <subsection> ------------------------------------------- -There is an important difference between the way disc-based c&b nodes -and devfs entries make the connection between an entry in /dev and the -actual device driver. + +Node to driver file_operations translation + +There is an important difference between the way disc-based character +and block nodes and devfs entries make the connection between an entry +in /dev and the actual device driver. With the current 8 bit major and minor numbers the connection between disc-based c&b nodes and per-major drivers is done through a @@ -178,7 +252,7 @@ Alternatively, you can use hashing to speed up the search. But why do that search at all if you don't have to? Once again, it seems pointless. -Note that the devfs doesn't use the major&minor system. For devfs +Note thate devfs doesn't use the major&minor system. For devfs entries, the connection is done when you lookup the /dev entry. When devfs_register() is called, an internal table is appended which has the entry name and the file_operations. If the dentry cache doesn't @@ -192,18 +266,19 @@ entries, not the number of *conceivable* entries. Even if you remove unnecessary entries in a disc-based /dev, the number of conceivable entries remains the same: you just limit yourself in order to save space. + Devfs provides a fast connection between a VFS node and the device driver, in a scalable way. -/dev as a system administration tool <subsection> ------------------------------------- +/dev as a system administration tool + Right now /dev contains a list of conceivable devices, most of which I don't have. A devfs would only show those devices available on my system. This means that listing /dev would be a handy way of checking what devices were available. -Major&minor size <subsection> ----------------- +Major&minor size + Existing major and minor numbers are limited to 8 bits each. This is now a limiting factor for some drivers, particularly the SCSI disc driver, which consumes a single major number. Only 16 discs are @@ -216,27 +291,42 @@ number). Since this is private to the kernel, there are no C library compatibility which you would have with increasing major and minor number sizes. See the section on "Allocation of Device Numbers" for details on maintaining compatibility with userspace. + Solving this requires a kernel change. -Read-only root filesystem <subsection> ------------------------- +Since writing this, the kernel has been modified so that the SCSI disc +driver has more major numbers allocated to it and now supports up to +128 discs. Since these major numbers are non-contiguous (a result of +unplanned expansion), the implementation is a little more cumbersome +than originally. + +Just like the changes to IPv4 to fix impending limitations in the +address space, people find ways around the limitations. In the long +run, however, solutions like IPv6 or devfs can't be put off forever. + +Read-only root filesystem + Having your device nodes on the root filesystem means that you can't operate properly with a read-only root filesystem. This is because you want to change ownerships and protections of tty devices. Existing practice prevents you using a CD-ROM as your root filesystem for a *real* system. Sure, you can boot off a CD-ROM, but you can't change tty ownerships, so it's only good for installing. + Also, you can't use a shared NFS root filesystem for a cluster of discless Linux machines (having tty ownerships changed on a common /dev is not good). Nor can you embed your root filesystem in a ROM-FS. + You can get around this by creating a RAMDISC at boot time, making an ext2 filesystem in it, mounting it somewhere and copying the contents of /dev into it, then unmounting it and mounting it over -/dev. A devfs is a cleaner way of solving this. +/dev. + +A devfs is a cleaner way of solving this. + +Non-Unix root filesystem -Non-Unix root filesystem <subsection> ------------------------- Non-Unix filesystems (such as NTFS) can't be used for a root filesystem because they variously don't support character and block special files or symbolic links. You can't have a separate disc-based @@ -248,20 +338,24 @@ root filesystem (which is populated with a minimal set of device nodes), and then construct a new /dev in another RAMDISC, and finally switch to your non-Unix root filesystem. This requires clever boot scripts and a fragile and conceptually complex boot procedure. + Devfs solves this in a robust and conceptually simple way. -PTY security <subsection> ------------- +PTY security + Current pseudo-tty (pty) devices are owned by root and read-writable by everyone. The user of a pty-pair cannot change ownership/protections without being suid-root. + This could be solved with a secure user-space daemon which runs as root and does the actual creation of pty-pairs. Such a daemon would require modification to *every* programme that wants to use this new mechanism. It also slows down creation of pty-pairs. + An alternative is to create a new open_pty() syscall which does much the same thing as the user-space daemon. Once again, this requires modifications to pty-handling programmes. + The devfs solution allows a device driver to "tag" certain device files so that when an unopened device is opened, the ownerships are changed to the current euid and egid of the opening process, and the @@ -272,8 +366,8 @@ The devpts filesystem provides this auto-ownership feature for Unix98 ptys. It doesn't support old-style pty devices, nor does it have all the other features of devfs. -Intelligent device management <subsection> ------------------------------ +Intelligent device management + Devfs implements a simple yet powerful protocol for communication with a device management daemon (devfsd) which runs in user space. It is possible to send a message (either synchronously or asynchronously) to @@ -281,7 +375,9 @@ devfsd on any event, such as registration/unregistration of device entries, opening and closing devices, looking up inodes, scanning directories and more. This has many possibilities. Some of these are already implemented. -See: http://www.atnf.csiro.au/~rgooch/linux/ + +See: +http://www.atnf.csiro.au/~rgooch/linux/ Device entry registration events can be used by devfsd to change permissions of newly-created device nodes. This is one mechanism to @@ -314,15 +410,15 @@ control lists, as access can be determined on the basis of other system conditions instead of just the UID and GID. Inode lookup events can be used to authenticate module autoload -requests. Instead of using kmod directly, the event can be sent to +requests. Instead of using kmod directly, the event is sent to devfsd which can implement an arbitrary authentication before loading the module itself. Inode lookup events can also be used to construct arbitrary namespaces, without having to resort to populating devfs with symlinks to devices that don't exist. -Speculative Device Scanning <subsection> ---------------------------- +Speculative Device Scanning + Consider an application (like cdparanoia) that wants to find all CD-ROM devices on the system (SCSI, IDE and other types), whether or not their respective modules are loaded. The application must @@ -340,31 +436,33 @@ inefficient operation, especially if there are many /dev/sr* nodes. A solution like scsidev could reduce the number of /dev/sr* entries (but of course that also requires all that inefficient directory scanning). -With devfs, the application can open the /dev/sr directory (which -triggers the module autoloading if required), and proceed to read -/dev/sr. Since only the available devices will have entries, there are -no inefficencies in directory scanning or device openings. +With devfs, the application can open the /dev/sr directory +(which triggers the module autoloading if required), and proceed to +read /dev/sr. Since only the available devices will have +entries, there are no inefficencies in directory scanning or device +openings. +----------------------------------------------------------------------------- -Who else does it? <section> -================= +Who else does it? -FreeBSD-current now has a devfs implementation. Solaris 2 has a -pseudo-devfs (something akin to scsidev but for all devices, with some -unspecified kernel support). BeOS, Plan9 and QNX also have it. SGI's -IRIX 6.4 and above also have a device filesystem. +FreeBSD has a devfs implementation. Solaris 2 has a pseudo-devfs +(something akin to scsidev but for all devices, with some unspecified +kernel support). BeOS, Plan9 and QNX also have it. SGI's IRIX 6.4 and +above also have a device filesystem. While we shouldn't just automatically do something because others do it, we should not ignore the work of others either. FreeBSD has a lot of competent people working on it, so their opinion should not be blithely ignored. +----------------------------------------------------------------------------- + + +How it works -How it works <section> -============ +Registering device entries -Registering device entries <subsection> --------------------------- For every entry (device node) in a devfs-based /dev a driver must call devfs_register(). This adds the name of the device entry, the file_operations structure pointer and a few other things to an @@ -372,18 +470,18 @@ internal table. Device entries may be added and removed at any time. When a device entry is registered, it automagically appears in any mounted devfs'. -Inode lookup <subsection> ------------- +Inode lookup + When a lookup operation on an entry is performed and if there is no -driver information for that entry devfs will attempt to call devfsd or -kmod. If still no driver information can be found then a negative +driver information for that entry devfs will attempt to call +devfsd. If still no driver information can be found then a negative dentry is yielded and the next stage operation will be called by the VFS (such as create() or mknod() inode methods). If driver information can be found, an inode is created (if one does not exist already) and all is well. -Manually creating device nodes <subsection> ------------------------------- +Manually creating device nodes + The mknod() method allows you to create an ordinary named pipe in the devfs, or you can create a character or block special inode if one does not already exist. You may wish to create a character or block @@ -393,72 +491,214 @@ permissions, ownership and times are retained. This is how you can set the protections on a device even before the driver is loaded. Once you create an inode it appears in the directory listing. -Unregistering device entries <subsection> ----------------------------- -A device driver calls devfs_unregister() to unregister an entry. - -Chroot() gaols <subsection> --------------- -The semantics of inode creation are different when the devfs is -mounted with the "explicit" option. Now, when a device entry is -registered, it will not appear until you use mknod() to create the -device. It doesn't matter if you mknod() before or after the device is -registered with devfs_register(). The purpose of this behaviour is to -support chroot(2) gaols, where you want to mount a minimal devfs -inside the gaol. Only the devices you specifically want to be -available (through your mknod() setup) will be accessible. +Unregistering device entries +A device driver calls devfs_unregister() to unregister an entry. -Persistence of ownership/permissions across reboots <section> -=================================================== +Chroot() gaols + +The semantics of inode creation are different when devfs is mounted +with the "explicit" option. Now, when a device entry is registered, it +will not appear until you use mknod() to create the device. It doesn't +matter if you mknod() before or after the device is registered with +devfs_register(). The purpose of this behaviour is to support +chroot(2) gaols, where you want to mount a minimal devfs inside the +gaol. Only the devices you specifically want to be available (through +your mknod() setup) will be accessible. + +----------------------------------------------------------------------------- + + +Operational issues + + +Instructions for the impatient + +Nobody likes reading documentation. People just want to get in there +and play. So this section tells you quickly the steps you need to take +to run with devfs mounted over /dev. Skip these steps and you will end +up with a nearly unbootable system. Subsequent sections describe the +issues in more detail, and discuss non-essential configuration +options. + +Devfsd +OK, if you're reading this, I assume you want to play with +devfs. First you need to compile devfsd, the device management daemon, +available at +http://www.atnf.csiro.au/~rgooch/linux/. +Because the kernel has a naming scheme +which is quite different from the old naming scheme, you need to +install devfsd so that software and configuration files that use the +old naming scheme will not break. + +Compile and install devfsd. You will be provided with a default +configuration file /etc/devfsd.conf which will provide +compatibility symlinks for the old naming scheme. Don't change this +config file unless you know what you're doing. Even if you think you +do know what you're doing, don't change it until you've followed all +the steps below and booted a devfs-enabled system and verified that it +works. + +Now edit your main system boot script so that devfsd is started at the +very beginning (before any filesystem +checks). /etc/rc.d/rc.sysinit is often the main boot script +on systems with SysV-style boot scripts. On systems with BSD-style +boot scripts it is often /etc/rc. Also check +/sbin/rc. + +NOTE that the line you put into the boot +script should be exactly: + +/sbin/devfsd /dev + +DO NOT use some special daemon-launching +programme, otherwise the boot script may not wait for devfsd to finish +initialising. + +System Libraries +There may still be some problems because of broken software making +assumptions about device names. In particular, some software does not +handle devices which are symbolic links. If you are running a libc 5 +based system, install libc 5.4.44 (if you have libc 5.4.46, go back to +libc 5.4.44, which is actually correct). If you are running a glibc +based system, make sure you have glibc 2.1.3 or later. + +/etc/securetty +PAM (Pluggable Authentication Modules) is supposed to be a flexible +mechanism for providing better user authentication and access to +services. Unfortunately, it's also fragile, complex and undocumented +(check out RedHat 6.1, and probably other distributions as well). PAM +has problems with symbolic links. Append the following lines to your +/etc/securetty file: + +1 +2 +3 +4 +5 +6 +7 +8 + +This may potentially weaken security by allowing root logins over the +network (a password is still required, though). However, since there +are problems with dealing with symlinks, I'm suspicious of the level +of security offered in any case. + +XFree86 +While not essential, it's probably a good idea to upgrade to XFree86 +4.0, as patches went in to make it more devfs-friendly. If you don't, +you'll probably need to apply the following patch to +/etc/security/console.perms so that ordinary users can run +startx. + +--- /etc/security/console.perms.orig Sat Apr 17 16:26:47 1999 ++++ /etc/security/console.perms Fri Feb 25 23:53:55 2000 +@@ -14,7 +14,7 @@ + # man 5 console.perms + + # file classes -- these are regular expressions +-=tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9] ++=tty[0-9][0-9]* [0-9][0-9]* :[0-9]\.[0-9] :[0-9] + + # device classes -- these are shell-style globs + =/dev/fd[0-1]* + + +Disable devpts +I've had a report of devpts mounted on /dev/pts not working +correctly. Since devfs will also manage /dev/pts, there is no +need to mount devpts as well. You should either edit your +/etc/fstab so devpts is not mounted, or disable devfs from +your kernel configuration. + +Unsupported drivers +Not all drivers have devfs support. If you depend on one of these +drivers, you will need to create a script or tarfile that you can use +at boot time to create device nodes as appropriate. There is a +section which describes this. Another +section lists the drivers which have +devfs support. + +/dev/mouse + +Many disributions configure /dev/mouse to be the mouse device +for XFree86 and GPM. I actually think this is a bad idea, because it +adds another level of indirection. When looking at a config file, if +you see /dev/mouse you're left wondering which mouse +is being referred to. Hence I recommend putting the actual mouse +device (for example /dev/psaux) into your +/etc/X11/XF86Config file (and similarly for the GPM +configuration file). + +Alternatively, use the same technique used for unsupported drivers +described above. + +The Kernel +Finally, you need to make sure devfs is compiled into your +kernel. Set CONFIG_DEVFS_FS=y and recompile your kernel. Next, you +need to make sure devfs is mounted. The best solution is to pass +devfs=mount at the kernel boot command line. You can edit +/etc/lilo.conf and add the line: + +append = "devfs=mount" + + +This will make the kernel mount devfs at boot time onto /dev. + +Now you've finished all the steps required. You're now ready to boot +your shiny new kernel. Enjoy. + +Changing the configuration + +OK, you've now booted a devfs-enabled system, and everything works. +Now you may feel like changing the configuration (common targets are +/etc/fstab and /etc/devfsd.conf). Since you have a +system that works, if you make any changes and it doesn't work, you +now know that you only have to restore your configuration files to the +default and it will work again. + + +Permissions persistence across reboots If you don't use mknod(2) to create a device file, nor use chmod(2) or chown(2) to change the ownerships/permissions, the inode ctime will remain at 0 (the epoch, 12 am, 1-JAN-1970, GMT). Anything with a ctime later than this has had it's ownership/permissions changed. Hence, a simple script or programme may be used to tar up all changed inodes, -prior to shutdown. - -Upon bootup, simply untar the previously created tarfile, and all your -ownerships/permissions will be retained. For the paranoid, you can -save your permissions periodically using a cron job. - -NOTE: tar will first unlink(2) an inode before creating a new device -node. The unlink(2) has the effect of breaking the connection between -a devfs entry and the device driver. If you use the "devfs=only" boot -option, you lose access to the device driver, requiring you to reload -the module. I consider this a bug in tar (there is no real need to +prior to shutdown. Although effective, many consider this approach a +kludge. + +A much better approach is to use devfsd to save and restore +permissions. It may be configured to record changes in permissions and +will save them in a database (in fact a directory tree), and restore +these upon boot. This is an efficient method and results in immediate +saving of current permissions (unlike the tar approach, which save +permissions at some unspecified future time). + +The default configuration file supplied with devfsd has config entries +which you may uncomment to enable persistence management. + +If you decide to use the tar approach anyway, be aware that tar will +first unlink(2) an inode before creating a new device node. The +unlink(2) has the effect of breaking the connection between a devfs +entry and the device driver. If you use the "devfs=only" boot option, +you lose access to the device driver, requiring you to reload the +module. I consider this a bug in tar (there is no real need to unlink(2) the inode first). -I've provided a script called "rc.devfs" in this directory which you -can use to save and restore permissions. - -Alternatively, you can use the device management daemon (devfsd) to -control the permissions of device nodes. This has the advantage of -being able to store permissions for whole groups of devices with a -single configuration entry, rather than one (tar) entry per device -node. Devfsd also receives inode change events, so you could easily -implement a simple permissions database. +Alternatively, you can use devfsd to provide more sophisticated +management of device permissions. You can use devfsd to store +permissions for whole groups of devices with a single configuration +entry, rather than the conventional single entry per device entry. -Installation during the transition phase <section> -======================================== +Dealing with drivers without devfs support Currently, not all device drivers in the kernel have been modified to -use devfs. If you want to boot between kernels with and without devfs -support, this section discusses some options. Either way is safe, -although some people will have different preferences. - -Note that your old-style (i.e. node-based) chroot /gaol/dev -directories which you manually created will still work, unless you -pass the "devfs=only" boot option. - -Fail-safe Approach with devfs mounted on /dev <subsection> ---------------------------------------------- -The default is for devfs to be mounted onto /dev at boot time. -Device drivers which do not yet have devfs support will not -automagically appear in the devfs. The simplest way to create device -nodes for these drivers is to unpack a tarfile containing the required +use devfs. Device drivers which do not yet have devfs support will not +automagically appear in devfs. The simplest way to create device nodes +for these drivers is to unpack a tarfile containing the required device nodes. You can do this in your boot scripts. All your drivers will now work as before. @@ -466,7 +706,7 @@ Hopefully for most people devfs will have enough support so that they can mount devfs directly over /dev without loosing most functionality (i.e. loosing access to various devices). As of 22-JAN-1998 (devfs patch version 10) I am now running this way. All the devices I have -are available in the devfs, so I don't lose anything. +are available in devfs, so I don't lose anything. WARNING: if your configuration requires the old-style device names (i.e. /dev/hda1 or /dev/sda1), you must install devfsd and configure @@ -478,7 +718,7 @@ Note that you no longer need to mount devpts if you use Unix98 PTYs, as devfs can manage /dev/pts itself. This saves you some RAM, as you don't need to compile and install devpts. Note that some versions of glibc have a bug with Unix98 pty handling on devfs systems. Contact -the glibc maintainers for a fix. +the glibc maintainers for a fix. Glibc 2.1.3 should have the fix. Note also that apart from editing /etc/fstab, other things will need to be changed if you *don't* install devfsd. Some software (like the X @@ -487,6 +727,7 @@ easier to install devfsd so that compatibility entries are created. You can then slowly migrate your system to using the new device names (for example, by starting with /etc/fstab), and then limiting the compatibility entries that devfsd creates. + MAKE SURE YOU INSTALL DEVFSD BEFORE YOU BOOT A DEVFS-ENABLED KERNEL! Now that devfs has gone into the 2.3.46 kernel, I'm getting a lot of @@ -497,30 +738,8 @@ misconfiguration problems at the moment. If people are willing to fix bugs/false assumptions in other code (i.e. glibc, X server) and submit that to the respective maintainers, that would be great. -Fail-safe Approach with real /dev inodes <subsection> ----------------------------------------- -This method involves more work, and is no longer recommended now that -a large number of drivers have devfs support. You will need to use the -"devfs=nomount" boot option. - -Copy the contents of /dev to /devfs. Then remove entries in /dev -which are now available in devfs and make them symbolic links to the -entries in /devfs. Finally, edit your /etc/fstab or boot scripts so -that devfs is mounted over /devfs on bootup. If devfs is supported, -accessing devices supported by devfs will follow the symlinks to -devfs. If devfs is not supported, accessing those same devices will -follow the symlinks to /devfs which contains only old-style device -nodes. Devices not supported by devfs will be found directly on /dev. -Simple! You can also follow this principle for chroot gaols. - -I've provided a demonstration script called "mk-devlinks" in this -directory which you can use to create symlinks in /dev and -/devfs. Note that this script is out of date and should not be run -without modification. - -All the way with Devfs <section> -====================== +All the way with Devfs The devfs kernel patch creates a rationalised device tree. As stated above, if you want to keep using the old /dev naming scheme, you just @@ -542,24 +761,49 @@ BSD pseudo-terminal devices (otherwise you'll have to patch you C library or use Unix98 ptys instead). It's just a matter of putting in the correct regular expression into /dev/devfsd.conf. - -Other Issues <section> -============ - -Another thing to take note of is whether your init programme creates a -Unix socket /dev/telinit. Some versions of init create /dev/telinit so -that the <telinit> programme can communicate with the init process. If -you have such a system you need to make sure that devfs is mounted -over /dev *before* init starts. In other words, you can't leave the -mounting of devfs to /etc/rc, since this is executed after init. -Other versions of init require a named pipe /dev/initctl which must -exist *before* init starts. Once again, you need to mount devfs and -then create the named pipe *before* init starts. - -The default behaviour now is to mount devfs onto /dev at boot time. -You can disable this with the "devfs=nomount" boot option, but you can -then get harmless but annoying messages about not being able to open -an initial console. +There are other choices of naming schemes that you may prefer. For +example, I don't use the kernel-supplied +names, because they are too verbose. A common misconception is +that the kernel-supplied names are meant to be used directly in +configuration files. This is not the case. They are designed to +reflect the layout of the devices attached and to provide easy +classification. + +If you like the kernel-supplied names, that's fine. If you don't then +you should be using devfsd to construct a namespace more to your +liking. Devfsd has built-in code to construct a +namespace that is both logical and easy to +manage. In essence, it creates a convenient abbreviation of the +kernel-supplied namespace. + +You are of course free to build your own namespace. Devfsd has all the +infrastructure required to make this easy for you. All you need do is +write a script. You can even write some C code and devfsd can load the +shared object as a callable extension. + + +Other Issues + +The init programme +Another thing to take note of is whether your init programme +creates a Unix socket /dev/telinit. Some versions of init +create /dev/telinit so that the telinit programme can +communicate with the init process. If you have such a system you need +to make sure that devfs is mounted over /dev *before* init +starts. In other words, you can't leave the mounting of devfs to +/etc/rc, since this is executed after init. Other +versions of init require a named pipe /dev/initctl +which must exist *before* init starts. Once again, you need to +mount devfs and then create the named pipe *before* init +starts. + +The default behaviour now is not to mount devfs onto /dev at boot time. +You can correct this with the "devfs=mount" boot option. This solves +any problems with init, and also prevents the dreaded: + +Cannot open initial console + +message. If you have automatic mounting of devfs onto /dev then you may need to create /dev/initctl in your boot scripts. The following lines should @@ -582,30 +826,39 @@ exec /sbin/init.real $* [control-D] # chmod a+x init -Note that newer versions of init create /dev/initctl automatically, so -you don't have to worry about this. +Note that newer versions of init create /dev/initctl +automatically, so you don't have to worry about this. + +Module autoloading +Another thing to note is that if you want to support module +autoloading then you need to edit your /etc/modules.conf so +that things work properly. You should include the sample +modules.conf file in the +Documentation/filesystems/devfs directory into your +/etc/modules.conf to ensure correct operation. -Using kmod (module autoloading) <subsection> -------------------------------- -Another thing to note is that if you are using kmod then you need to -edit your /etc/modules.conf so that things work properly. You should -include the sample modules.conf file in the -Documentation/filesystems/devfs directory into your /etc/modules.conf -to ensure correct operation. +You will also need to configure devfsd to enable module +autoloading. The following lines should be placed in your +/etc/devfsd.conf: -Mounting root off a devfs device <subsection> --------------------------------- +LOOKUP .* MODLOAD + + +Mounting root off a devfs device If you wish to mount root off a devfs device when you pass the -"devfs=only" boot option, then you need to pass in the "root=<device>" +"devfs=only" boot option, then you need to pass in the "root=" option to the kernel when booting. If you use LILO, then you must have this in lilo.conf: -append = "root=<device>" + +append = "root=" Surprised? Yep, so was I. It turns out if you have (as most people do): -root = <device> -then LILO will determine the device number of <device> and will write +root = + + +then LILO will determine the device number of and will write that device number into a special place in the kernel image before starting the kernel, and the kernel will use that device number to mount the root filesystem. So, using the "append" variety ensures that @@ -614,104 +867,64 @@ then use. Note that this isn't an issue if you don't pass "devfs=only". -TTY issues <subsection> ----------- -You may replace your tty devices in /dev with symbolic links to /devfs -however you will then find that programmes which depend on ttyname(3) -will no longer work properly. The <tty> programme is a good -example. I've written a patch to libc 5.4.43 which fixes this. This -has been included in libc 5.4.44 and glibc 2.1.? +TTY issues +The ttyname(3) function in some versions of the C library makes +false assumptions about device entries which are symbolic links. The +tty(1) programme is one that depends on this function. I've +written a patch to libc 5.4.43 which fixes this. This has been +included in libc 5.4.44 and a similar fix is in glibc 2.1.3. -Device drivers currently ported <section> -=============================== +Kernel Naming Scheme -- All miscellaneous character devices support devfs (this is done - transparently through misc_register()) - -- SCSI discs and generic hard discs +The kernel provides a default naming scheme. This scheme is designed +to make it easy to search for specific devices or device types, and to +view the available devices. Some device types (such as hard discs), +have a directory of entries, making it easy to see what devices of +that class are available. Often, the entries are symbolic links into a +directory tree that reflects the topology of available devices. The +topological tree is useful for finding how your devices are arranged. -- Character memory devices (null, zero, full and so on) - Thanks to C. Scott Ananian <cananian@alumni.princeton.edu> - -- Loop devices (/dev/loop?) - -- TTY devices (console, serial ports, terminals and pseudo-terminals) - Thanks to C. Scott Ananian <cananian@alumni.princeton.edu> - -- SCSI tapes (/dev/scsi and /dev/tapes) - -- SCSI CD-ROMs (/dev/scsi and /dev/cdroms) - -- SCSI generic devices (/dev/scsi) - -- RAMDISCS (/dev/ram?) - -- Meta Devices (/dev/md*) - -- Floppy discs (/dev/floppy) - -- Parallel port printers (/dev/printers) - -- Sound devices (/dev/sound) - Thanks to Eric Dumas <dumas@linux.eu.org> and - C. Scott Ananian <cananian@alumni.princeton.edu> - -- Joysticks (/dev/joysticks) - -- Sparc keyboard (/dev/kbd) - -- DSP56001 digital signal processor (/dev/dsp56k) - -- Apple Desktop Bus (/dev/adb) - -- Coda network file system (/dev/cfs*) - -- Virtual console capture devices (/dev/vcc) - Thanks to Dennis Hou <smilax@mindmeld.yi.org> - -- Frame buffer devices (/dev/fb) - -- Video capture devices (/dev/v4l) - - -Naming Scheme <section> -============= - -Disc Devices <subsection> ------------- +Disc Devices All discs, whether SCSI, IDE or whatever, are placed under the /dev/discs hierarchy: + /dev/discs/disc0 first disc /dev/discs/disc1 second disc + Each of these entries is a symbolic link to the directory for that device. The device directory contains: + disc for the whole disc part* for individual partitions -CD-ROM Devices <subsection> --------------- + +CD-ROM Devices All CD-ROMs, whether SCSI, IDE or whatever, are placed under the /dev/cdroms hierarchy: + /dev/cdroms/cdrom0 first CD-ROM /dev/cdroms/cdrom1 second CD-ROM + Each of these entries is a symbolic link to the real device entry for that device. -Tape Devices <subsection> ------------- +Tape Devices All tapes, whether SCSI, IDE or whatever, are placed under the /dev/tapes hierarchy: + /dev/tapes/tape0 first tape /dev/tapes/tape1 second tape + Each of these entries is a symbolic link to the directory for that device. The device directory contains: + mt for mode 0 mtl for mode 1 mtm for mode 2 @@ -721,20 +934,25 @@ device. The device directory contains: mtmn for mode 2, no rewind mtan for mode 3, no rewind -SCSI Devices <subsection> ------------- + +SCSI Devices + To uniquely identify any SCSI device requires the following information: + controller (host adapter) bus (SCSI channel) target (SCSI ID) unit (Logical Unit Number) -All SCSI devices are placed under /dev/scsi (assuming devfs is mounted -on /dev). Hence, a SCSI device with the following parameters: -c=1,b=2,t=3,u=4 would appear as: + +All SCSI devices are placed under /dev/scsi (assuming devfs +is mounted on /dev). Hence, a SCSI device with the following +parameters: c=1,b=2,t=3,u=4 would appear as: + /dev/scsi/host1/bus2/target3/lun4 device directory + Inside this directory, a number of device entries may be created, depending on which SCSI device-type drivers were installed. @@ -745,32 +963,38 @@ See the section on the tape naming scheme to see what entries the SCSI tape driver creates. The SCSI CD-ROM driver creates: + cd + The SCSI generic driver creates: + generic -IDE Devices <subsection> ------------ + +IDE Devices + To uniquely identify any IDE device requires the following information: + controller bus (aka. primary/secondary) target (aka. master/slave) unit -All IDE devices are placed under /dev/ide (assuming devfs is mounted -on /dev), and uses a similar naming scheme to the SCSI subsystem. +All IDE devices are placed under /dev/ide, and uses a similar +naming scheme to the SCSI subsystem. + +XT Hard Discs + +All XT discs are placed under /dev/xd. The first XT disc has +the directory /dev/xd/disc0. -XT Hard Discs <subsection> -------------- -All XT discs are placed under /dev/xd (assuming devfs is mounted on -/dev). The first XT disc has the directory /dev/xd/disc0 +TTY devices -TTY devices <subsection> ------------ The tty devices now appear as: + New name Old-name Device Type -------- -------- ----------- /dev/tts/{0,1,...} /dev/ttyS{0,1,...} Serial ports @@ -780,33 +1004,133 @@ The tty devices now appear as: /dev/pty/m{0,1,...} /dev/ptyp?? PTY masters /dev/pty/s{0,1,...} /dev/ttyp?? PTY slaves -RAMDISCS <subsection> --------- + +RAMDISCS + The RAMDISCS are placed in their own directory, and are named thus: + /dev/rd/{0,1,2,...} -Meta Devices <subsection> ------------- + +Meta Devices + The meta devices are placed in their own directory, and are named thus: + /dev/md/{0,1,2,...} -Floppy discs <subsection> ------------- + +Floppy discs + Floppy discs are placed in the /dev/floppy directory. -Loop devices <subsection> ------------- +Loop devices + Loop devices are placed in the /dev/loop directory. -Sound devices <subsection> -------------- -Sound devices are placed in the /dev/sound directory (audio, -sequencer, ...). +Sound devices + +Sound devices are placed in the /dev/sound directory +(audio, sequencer, ...). + + +Devfsd Naming Scheme + +Devfsd provides a naming scheme which is a convenient abbreviation of +the kernel-supplied namespace. In some +cases, the kernel-supplied naming scheme is quite convenient, so +devfsd does not provide another naming scheme. The convenience names +that devfsd creates are in fact the same names as the original devfs +kernel patch created (before Linus mandated the Big Name Change). + +In order to configure devfsd to create these convenience names, the +following lines should be placed in your /etc/devfsd.conf: + +REGISTER .* MKNEWCOMPAT +UNREGISTER .* RMNEWCOMPAT + +This will cause devfsd to create (and destroy) symbolic links which +point to the kernel-supplied names. + +SCSI Hard Discs + +All SCSI discs are placed under /dev/sd (assuming devfs is +mounted on /dev). Hence, a SCSI disc with the following +parameters: c=1,b=2,t=3,u=4 would appear as: + + /dev/sd/c1b2t3u4 for the whole disc + /dev/sd/c1b2t3u4p5 for the 5th partition + /dev/sd/c1b2t3u4p5s6 for the 6th slice in the 5th partition + + +SCSI Tapes +All SCSI tapes are placed under /dev/st. A similar naming +scheme is used as for SCSI discs. A SCSI tape with the +parameters:c=1,b=2,t=3,u=4 would appear as: -SCSI Host Probing Issues <section> -======================== + /dev/st/c1b2t3u4m0 for mode 0 + /dev/st/c1b2t3u4m1 for mode 1 + /dev/st/c1b2t3u4m2 for mode 2 + /dev/st/c1b2t3u4m3 for mode 3 + /dev/st/c1b2t3u4m0n for mode 0, no rewind + /dev/st/c1b2t3u4m1n for mode 1, no rewind + /dev/st/c1b2t3u4m2n for mode 2, no rewind + /dev/st/c1b2t3u4m3n for mode 3, no rewind + + +SCSI CD-ROMs + +All SCSI CD-ROMs are placed under /dev/sr. A similar naming +scheme is used as for SCSI discs. A SCSI CD-ROM with the +parameters:c=1,b=2,t=3,u=4 would appear as: + + /dev/sr/c1b2t3u4 + + +SCSI Generic Devices + +All SCSI CD-ROMs are placed under /dev/sg. A similar naming +scheme is used as for SCSI discs. A SCSI generic device with the +parameters:c=1,b=2,t=3,u=4 would appear as: + + /dev/sg/c1b2t3u4 + + +IDE Hard Discs + +All IDE discs are placed under /dev/ide/hd, using a similar +convention to SCSI discs. The following mappings exist between the new +and the old names: + + /dev/hda /dev/ide/hd/c0b0t0u0 + /dev/hdb /dev/ide/hd/c0b0t1u0 + /dev/hdc /dev/ide/hd/c0b1t0u0 + /dev/hdd /dev/ide/hd/c0b1t1u0 + + +IDE Tapes + +A similar naming scheme is used as for IDE discs. The entries will +appear in the /dev/ide/mt directory. + +IDE CD-ROM + +A similar naming scheme is used as for IDE discs. The entries will +appear in the /dev/ide/cd directory. + +IDE Floppies + +A similar naming scheme is used as for IDE discs. The entries will +appear in the /dev/ide/fd directory. + +XT Hard Discs + +All XT discs are placed under /dev/xd. The first XT disc +would appear as /dev/xd/c0t0. + + +SCSI Host Probing Issues Devfs allows you to identify SCSI discs based in part on SCSI host numbers. If you have only one SCSI host (card) in your computer, then @@ -818,14 +1142,16 @@ easy, there is a kernel boot parameter called "scsihosts". This allows you to specify the probe order for different types of SCSI hosts. The syntax of this parameter is: -scsihosts=<name_1>:<name_2>:<name_3>:...:<name_n> +scsihosts=:::...: -where <name_1>,<name_2>,...,<name_n> are the names of drivers used in +where ,,..., are the names of drivers used in /proc filesystem. For example: scsihosts=aha1542:ppa:aha1542::ncr53c7xx + means that devices connected to + - first aha1542 controller - will be c0b#t#u# - first parallel port ZIP - will be c1b#t#u# - second aha1542 controller - will be c2b#t#u# @@ -835,23 +1161,80 @@ means that devices connected to not be used by any other device. - c3b#t#u# names will never be used + You can use ',' instead of ':' as the separator character if you -wish. +wish. I have used the devfsd naming scheme +here. Note that this scheme does not address the SCSI host order if you have multiple cards of the same type (such as NCR53c8xx). In this case you need to use the driver-specific boot parameters to control this. +----------------------------------------------------------------------------- + + +Device drivers currently ported + +- All miscellaneous character devices support devfs (this is done + transparently through misc_register()) + +- SCSI discs and generic hard discs + +- Character memory devices (null, zero, full and so on) + Thanks to C. Scott Ananian <cananian@alumni.princeton.edu> + +- Loop devices (/dev/loop?) + +- TTY devices (console, serial ports, terminals and pseudo-terminals) + Thanks to C. Scott Ananian <cananian@alumni.princeton.edu> + +- SCSI tapes (/dev/scsi and /dev/tapes) + +- SCSI CD-ROMs (/dev/scsi and /dev/cdroms) + +- SCSI generic devices (/dev/scsi) + +- RAMDISCS (/dev/ram?) + +- Meta Devices (/dev/md*) + +- Floppy discs (/dev/floppy) + +- Parallel port printers (/dev/printers) + +- Sound devices (/dev/sound) + Thanks to Eric Dumas <dumas@linux.eu.org> and + C. Scott Ananian <cananian@alumni.princeton.edu> + +- Joysticks (/dev/joysticks) + +- Sparc keyboard (/dev/kbd) + +- DSP56001 digital signal processor (/dev/dsp56k) + +- Apple Desktop Bus (/dev/adb) + +- Coda network file system (/dev/cfs*) + +- Virtual console capture devices (/dev/vcc) + Thanks to Dennis Hou <smilax@mindmeld.yi.org> + +- Frame buffer devices (/dev/fb) + +- Video capture devices (/dev/v4l) + -Allocation of Device Numbers <section> -============================ +----------------------------------------------------------------------------- + + +Allocation of Device Numbers Devfs allows you to write a driver which doesn't need to allocate a device number (major&minor numbers) for the internal operation of the kernel. However, there are a number of userspace programmes that use the device number as a unique handle for a device. An example is the -<find> programme, which uses device numbers to determine whether an -inode is on a different filesystem than another inode. The device +find programme, which uses device numbers to determine whether +an inode is on a different filesystem than another inode. The device number used is the one for the block device which a filesystem is using. To preserve compatibility with userspace programmes, block devices using devfs need to have unique device numbers allocated to @@ -864,9 +1247,11 @@ values are given for major&minor and pass them onto userspace. 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). +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 @@ -881,3 +1266,203 @@ 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 + + + +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 in the device +namespace, but have had no response. + + + + + +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 49 or 93 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 + + +simplying increasing the device number size is insufficient. Apart +from causing a lot of pain, it doesn't solve the management issues +with 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 + + + +----------------------------------------------------------------------------- + + +Other resources + + + +Douglas Gilbert has written a useful document at + +http://www.torque.net/sg/devfs_scsi.html which +explores the SCSI subsystem and how it interacts with devfs. + + + + + diff --git a/Documentation/filesystems/devfs/boot-options b/Documentation/filesystems/devfs/boot-options index 83acf9168..18a7e8302 100644 --- a/Documentation/filesystems/devfs/boot-options +++ b/Documentation/filesystems/devfs/boot-options @@ -4,14 +4,13 @@ Richard Gooch <rgooch@atnf.csiro.au> - 14-DEC-1999 + 30-APR-2000 -When either CONFIG_DEVFS_DEBUG or CONFIG_DEVFS_BOOT_OPTIONS are -enabled, you can pass several boot options to the kernel to control -devfs behaviour. The boot options are prefixed by "devfs=", and are -separated by commas. Spaces are not allowed. The syntax looks like -this: +When CONFIG_DEVFS_DEBUG is enabled, you can pass several boot options +to the kernel to debug devfs. The boot options are prefixed by +"devfs=", and are separated by commas. Spaces are not allowed. The +syntax looks like this: devfs=<option1>,<option2>,<option3> @@ -61,6 +60,8 @@ These control the default behaviour of devfs. The options are: show show unregistered devices by default +mount mount devfs onto /dev at boot time + nomount do not mount devfs onto /dev at boot time only disable non-devfs device nodes for devfs-capable drivers diff --git a/Documentation/filesystems/devfs/mk-devlinks b/Documentation/filesystems/devfs/mk-devlinks deleted file mode 100644 index 885ebdfff..000000000 --- a/Documentation/filesystems/devfs/mk-devlinks +++ /dev/null @@ -1,123 +0,0 @@ -#! /bin/csh -f - -# WARNING: make sure /devfs is not a mounted devfs - -cd /devfs -if (-e .devfsd) then - echo "/devfs must not be a mounted devfs" - exit 1 -endif -if ( ! -e null ) then - echo "Cannot find null device" - exit 1 -endif - - -# Make SCSI disc links. -# WARNING: this assumes your SCSI discs are numbered ID=0, ID=1, ID=2 and so on -set discs = (a b c d e f) -if ( ! -d sd ) mkdir sd -ln -sf /devfs/sd /dev - -@ scsi_id = 0 -while ($scsi_id < $#discs) - @ discnum = $scsi_id + 1 - ls -lF sd${discs[$discnum]} - rm /dev/sd${discs[$discnum]} - ln -s /devfs/sd${discs[$discnum]} /dev - ln -s ../sd${discs[$discnum]} sd/c0b0t${scsi_id}u0 - @ partition = 1 - while ($partition < 16) - ls -lF sd${discs[$discnum]}${partition} - rm /dev/sd${discs[$discnum]}${partition} - ln -s /devfs/sd${discs[$discnum]}${partition} /dev - ln -s ../sd${discs[$discnum]}${partition} sd/c0b0t${scsi_id}u0p$partition - @ partition ++ - end - @ scsi_id ++ -end - - -# Make IDE disc links -foreach i (hd*) - rm /dev/$i - ln -s /devfs/$i /dev -end - - -# Make miscellaneous character devices links (character, major=10) -foreach i (`ls -l * | grep '^c' | fgrep '10,' | awk '{print $10}'`) - rm /dev/$i - ln -s /devfs/$i /dev -end - - -# Make memory devices links (character, major=1) -foreach i (`ls -l * | grep '^c' | fgrep ' 1,' | awk '{print $10}'`) - rm /dev/$i - ln -s /devfs/$i /dev -end - - -# Make loop device links -foreach i (loop*) - rm /dev/$i - ln -s /devfs/$i /dev -end - - -# Make various tty device links -foreach i (tty* pty* cua* console) - rm /dev/$i - ln -s /devfs/$i /dev -end - - -# Make SCSI CD-ROM, tapes and generic links -ln -s /devfs/sr /dev -ln -s /devfs/st /dev -ln -s /devfs/sg /dev -foreach i (sr* st* nst* sg*) - if ("$i" == "stderr") continue - if ("$i" == "stdin") continue - if ("$i" == "stdout") continue - rm /dev/$i - ln -s /devfs/$i /dev -end - - -# Make RAMDISC device links -ln -s /devfs/rd /dev -foreach i (ram*) - rm /dev/$i - ln -s /devfs/$i /dev -end - - -# Make floppy device links -ln -s /devfs/floppy /dev -foreach i (fd?*) - rm /dev/$i - ln -s /devfs/$i /dev -end - - -# Make line printer device links -foreach i (lp*) - rm /dev/$i - ln -s /devfs/$i /dev -end - -# Make sound devices links -if ( ! -d sound ) mkdir sound -ln -sf /devfs/sound /dev -foreach i (mixer sequencer midi dsp audio sequencer2 mixer1 patmgr0 midi1\ - dsp1 audio1 patmgr1 midi2 midi3) - - if ( -f /dev/$i ) then - rm /dev/$i - ln -s /devfs/$i /dev - endif -end - - diff --git a/Documentation/filesystems/devfs/modules.conf b/Documentation/filesystems/devfs/modules.conf index 43bae68ec..d925cd28b 100644 --- a/Documentation/filesystems/devfs/modules.conf +++ b/Documentation/filesystems/devfs/modules.conf @@ -84,6 +84,9 @@ alias /dev/atibm atixlmouse alias /dev/inportbm msbusmouse alias /dev/logibm busmouse +# PPP devices +alias /dev/ppp* ppp_generic + # Video capture devices alias /dev/video* /dev/v4l alias /dev/vbi* /dev/v4l diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt index 8e7505bd4..7f8794cf6 100644 --- a/Documentation/filesystems/ntfs.txt +++ b/Documentation/filesystems/ntfs.txt @@ -12,6 +12,9 @@ volume sets on top of the md driver, although mirror and stripe sets should work as well - if the md driver can be talked into using the same layout as Windows NT. +Please note that the experimental write support is limited to +Windows NT4 and earlier versions. + The ntfs driver supports the following mount options: iocharset=name Character set to use when returning file names. Unlike VFAT, NTFS suppresses names that contain diff --git a/Documentation/IO-APIC.txt b/Documentation/i386/IO-APIC.txt index 1a7dbd410..1a7dbd410 100644 --- a/Documentation/IO-APIC.txt +++ b/Documentation/i386/IO-APIC.txt diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt index bb8e3ee46..273c954e5 100644 --- a/Documentation/ioctl-number.txt +++ b/Documentation/ioctl-number.txt @@ -179,5 +179,6 @@ Code Seq# Include File Comments <mailto:rusty@rustcorp.com.au> 0xB0 all RATIO devices in development: <mailto:vgo@ratio.de> +0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca> 0xCB 00-1F CBM serial IEC bus in development: <mailto:michael.klein@puffin.lb.shuttle.de> diff --git a/Documentation/kbuild/config-language.txt b/Documentation/kbuild/config-language.txt index 357dc5122..c446e7ac3 100644 --- a/Documentation/kbuild/config-language.txt +++ b/Documentation/kbuild/config-language.txt @@ -465,7 +465,7 @@ Example: Known bugs: - Xconfig does not write "# foo is not set" to .config (as well as - "#unset foo" to autoconf.h) if command is disabled by its dependencies. + "#undef foo" to autoconf.h) if command is disabled by its dependencies. === dep_mbool /prompt/ /symbol/ /dep/ ... @@ -497,7 +497,7 @@ Example: Known bugs: - Xconfig does not write "# foo is not set" to .config (as well as - "#unset foo" to autoconf.h) if command is disabled by its dependencies. + "#undef foo" to autoconf.h) if command is disabled by its dependencies. === dep_hex /prompt/ /symbol/ /word/ /dep/ ... @@ -540,7 +540,7 @@ Example: Known bugs: - Xconfig does not write "# foo is not set" to .config (as well as - "#unset foo" to autoconf.h) if command is disabled by its dependencies. + "#undef foo" to autoconf.h) if command is disabled by its dependencies. === unset /symbol/ ... diff --git a/Documentation/networking/8139too.txt b/Documentation/networking/8139too.txt index 6a75c7338..92427b679 100644 --- a/Documentation/networking/8139too.txt +++ b/Documentation/networking/8139too.txt @@ -169,6 +169,33 @@ suggestions welcome) Change History -------------- +Version 0.9.4.1 - April 27, 2000 - third public beta release + +* Replace several "magic numbers" with symbolic constants +* Differentiate between board-specific info and chip-specific info + (allows for easier support of specific boards or chips) +* Move some of the transmit side outside of the spinlock + by using atomic variables. Use spin_lock_irq instead of + spin_lock_irq{save,restore} in select places, for better performance. +* New module option "media" for forcing media selection. Functions the + same as "options" in other drivers, and will soon be renamed + 'options' to be homogeneous. +* New power management wake-up code +* Slightly more verbose chip id messages in kernel log +* Add/correct chip register constant list +* New chipset wake up (open) logic +* No longer locks CONFIGx updates +* Do not set Interfame Gap (IFG) bits in TxConfig +* Better Rx reset logic in case of Rx FIFO Overflow +* For chips which support it, enable bit to automatically clear Rx + FIFO overflow +* No longer enable and disable interrupts in interrupt handler + (technique borrowed from BSD driver, appears to have problems + with some chips) +* H/W spinlock now protects ioctl +* Chipset-dependent RxConfig settings + + Version 0.9.3.3.2 - Feb 22, 2000 - second public beta release * Begin integration of Daniel Kobras' MMIO flush patch (disabled for now) @@ -187,8 +214,9 @@ Version 0.9.3.3.2 - Feb 22, 2000 - second public beta release * Reset NWay registers to sane defaults on rtl8139_open/hw_start * Miscellaneous code cleanup -Version 0.7.0 - Feb 7, 2000 - first public beta release +Version 0.7.0 - Feb 7, 2000 - first public beta release +* Initial public version, derived from Donald Becker's rtl8139.c v1.08r [EOF] diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt index 1eebbfef5..850ce4838 100644 --- a/Documentation/networking/vortex.txt +++ b/Documentation/networking/vortex.txt @@ -1,5 +1,10 @@ +Documentation/networking/vortex.txt +Andrew Morton <andrewm@uow.edu.au> +30 April 2000 + + This document describes the usage and errata of the 3Com "Vortex" device -driver for Linux. +driver for Linux, 3c59x.c. The driver was written by Donald Becker <becker@cesdis.gsfc.nasa.gov> @@ -8,7 +13,14 @@ Please report problems to one or more of: Andrew Morton <andrewm@uow.edu.au> Netdev mailing list <netdev@oss.sgi.com> + Linux kernel mailing list <linux-kernel@vger.rutgers.edu> + +Please note the 'Reporting and Diagnosing Problems' section at the end +of this file. + +Since kernel 2.3.99-pre6, this driver incorporates the support for the +3c575-series Cardbus cards which used to be handled by 3c575_cb.c. This driver supports the following hardware: @@ -42,55 +54,133 @@ This driver supports the following hardware: 3c450 Cyclone/unknown 3Com Boomerang (unknown version) -When loaded as a module the following variables may be set: - name type description - debug int The debug message level, 0 (no messages) to 6 (wordy). - options int[] The media type override and card operation settings - (See list below.) -An example of loading the vortex module is - insmod 3c59x.o debug=1 options=0,,12 -This sets the debug message level to minimal messages, sets the first card to -the 10baseT transceiver, the second to the EEPROM-set transceiver, and the -third card to operate in full-duplex mode using its 100baseTx transceiver. -(Note: card ordering is set by the PCI BIOS.) +Module parameters +================= + +There are several parameters which may be provided to the driver when +its module is loaded. These are usually placed in /etc/modules.conf +(used to be conf.modules). Example: + +options 3c59x debug=3 rx_copybreak=300 + +If you are using the PCMCIA tools (cardmgr) then theoptions may be +placed in /etc/pcmcia/config.opts: + +module "3c59x" opts "debug=3 extra_reset=1" + + +The supported parameters are: + +debug=N + + Where N is a number from 0 to 7. Anything above 3 produces a lot + of output in your system logs. debug=1 is default. + +options=N1,N2,N3,... + + Each number in the list provides an option to the corresponding + network card. So if you have two 3c905's and you wish to provide + them with option 0x204 you would use: -Possible media type settings + options=0x204,0x204 + + The individual options are composed of a number of bitfields which + have the following meanings: + + ssible media type settings 0 10baseT 1 10Mbs AUI 2 undefined 3 10base2 (BNC) 4 100base-TX 5 100base-FX - 6 MII (not yet available) - 7 <Use default setting> - - 8 Full-duplex bit - 8 10baseT full-duplex - 12 100baseTx full-duplex - 16 Bus-master enable bit (experimental use only!) + 6 MII (Media Independent Interface) + 7 Use default setting from EEPROM + 8 Autonegotiate + 9 External MII + 10 Use default setting from EEPROM -Details of the device driver implementation are at the top of the source file. + When generating a value for the 'options' setting, the above media + selection values may be OR'ed (or added to) the following: -Additional documentation is available at Don Becker's Linux Drivers site: + 512 (0x200) Force full-duplex + 16 (0x10) Bus-master enable bit (Old Vortex cards only) + + For example: + + insmod 3c59x options=0x204 + + will force full-duplex 100base-TX, rather than allowing the usual + autonegotiation. + +full_duplex=N1,N2,N3... + + Similar to bit 9 of 'options'. Forces the corresponding card into + full-duplex mode. + +rx_copybreak=M + + The driver preallocates 32 full-sized (1536 byte) network buffers + for receiving. When a packet arrives, the driver has to decide + whether to leave the packet in its full-sized buffer, or to allocate + a smaller buffer and copy the packet across into it. + + This is a speed/space tradeoff. + + The value of rx_copybreak is used to decide when to make the copy. + If the packet size is less than rx_copybreak, the packet is copied. + The default value for rx_copybreak is 200 bytes. + +max_interrupt_work=N + + The driver's interrupt service routine can handle many receive and + transmit packets in a single invokation. It does this in a loop. + The value of max_interrupt_work governs how mnay times the interrupt + service routine will loop. The default value is 32 loops. If this + is exceeded the interrupt service routine gives up and generates a + warning message "eth0: Too much work in interrupt". + +extra_reset=N + + Where N is 0 or 1 (default 0). + + Some network cards (notably 3CCFE575CT Cardbus) do not initialise + correctly and need an extra transmitter reset. If you find that the + card comes up receiving but not transmitting, try giving the module + the 'extra_reset=1' option. + +compaq_ioaddr=N +compaq_irq=N +compaq_device_id=N + + "Variables to work-around the Compaq PCI BIOS32 problem".... - http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html Additional resources -------------------- +Details of the device driver implementation are at the top of the source file. + +Additional documentation is available at Don Becker's Linux Drivers site: + + http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html + Donald Becker's driver development site: + http://www.scyld.com http://cesdis.gsfc.nasa.gov/linux/ Don's vortex-diag program is useful for inspecting the NIC's state: + http://www.scyld.com/diag/#pci-diags http://cesdis.gsfc.nasa.gov/linux/diag/vortex-diag.c Don's mii-diag program may be used for inspecting and manipulating the NIC's Media Independent Interface subsystem: + http://www.scyld.com/diag/#mii-diag http://cesdis.gsfc.nasa.gov/linux/diag/#mii-diag 3Com's documentation for many NICs, including the ones supported by @@ -104,8 +194,16 @@ series kernel is available at http://www.uow.edu.au/~andrewm/linux/#3c59x-2.3 +Autonegotiation notes +--------------------- + + The driver uses a one-minute heartbeat for adapting to changes in + the external LAN environment. This means that when, for example, a + machine is unplugged from a hubbed 10baseT LAN plugged into a + switched 100baseT LAN, the throughput will be quite dreadful for up + to sixty seconds. Be patient. -Cisco interoperability note from Walter Wong <wcw+@CMU.EDU>: + Cisco interoperability note from Walter Wong <wcw+@CMU.EDU>: On a side note, adding HAS_NWAY seems to share a problem with the Cisco 6509 switch. Specifically, you need to change the spanning @@ -114,3 +212,32 @@ Cisco interoperability note from Walter Wong <wcw+@CMU.EDU>: we've noticed for a while but haven't had the time to track down. +Reporting and diagnosing problems +--------------------------------- + +If the driver plays up, there are a number of things you can do analyse +the problem and to help others do this: + +- Turn on debugging in the driver + Add 'debug=7' to /etc/modules.conf (/etc/conf.modules) + Change 'vortex_debug' to 7 in the source code. + +- Send all kernel logs, starting with the first probe of the card. + +- Run 'mii-diag -v' to show the state of the Media Independent + Interface. If the card sometimes works and sometimes doesn't, run + 'mii-diag -v' in both states. + +- Please run 'vortex-diag -aaee' in both good and bad states. This + show the NIC's registers and EEPROM contents. + +- Describe your setup: 10baseT, 100baseT, full/half duplex, etc. + +- Note any additional module insertion commands you're using. + +- Try different media type settings (see above). + +- Try inserting the module with 'extra_reset=1' (or compile this into + the driver). + + diff --git a/Documentation/pci.txt b/Documentation/pci.txt index f09ece79a..63e035a93 100644 --- a/Documentation/pci.txt +++ b/Documentation/pci.txt @@ -43,7 +43,10 @@ contains: name Name of the driver id_table Pointer to table of device ID's the driver is - interested in + interested in. Most drivers should export this + table using MODULE_DEVICE_TABLE(pci,...). + Set to NULL to call probe() function for every + PCI device known to the system. probe Pointer to a probing function which gets called (during execution of pci_register_driver for already existing devices or later if a new device gets inserted) for all @@ -59,9 +62,8 @@ contains: deregistration of the driver or when it's manually pulled out of a hot-pluggable slot). This function can be called from interrupt context. - suspend, Power management hooks (currently used only for CardBus - resume cards) -- called when the device goes to sleep or is - resumed. + suspend, Power management hooks -- called when the device goes to + resume sleep or is resumed. The ID table is an array of struct pci_device_id ending with a all-zero entry. Each entry consists of: diff --git a/Documentation/sound/Maestro b/Documentation/sound/Maestro index b7e1334cd..940156fc6 100644 --- a/Documentation/sound/Maestro +++ b/Documentation/sound/Maestro @@ -30,7 +30,8 @@ Driver OSS Behavior -------------------- This OSS driver exports /dev/mixer and /dev/dsp to applications, which -mostly adhere to the OSS spec. +mostly adhere to the OSS spec. This driver doesn't register itself +with /dev/sndstat, so don't expect information to appear there. The /dev/dsp device exported behaves almost as expected. Playback is supported in all the various lovely formats. 8/16bit stereo/mono from diff --git a/Documentation/sound/via82cxxx.txt b/Documentation/sound/via82cxxx.txt index 5bb587950..af963c3b4 100644 --- a/Documentation/sound/via82cxxx.txt +++ b/Documentation/sound/via82cxxx.txt @@ -13,12 +13,11 @@ The via82cxxx audio driver found in the drivers/sound directory of the kernel source tree is a PCI audio driver for audio chips found on Via-based motherboards, such as the MVP4. -Currently the driver provides audio via SoundBlaster Pro compatibility, -and MIDI via MPU-401 compatibility. An AC97 mixing device is also -supported, and is generally preferred over the SoundBlaster mixer. +Currently the driver exports the following features: -IMPORTANT NOTE: Some users report that the SoundBlaster mixer does -not work at all -- use the AC97 mixer if possible. + * /dev/dsp and /dev/audio support + * 16-bit stereo PCM output channel + * AC97 mixer Please send bug reports to the mailing list linux-via@gtf.org. To subscribe, e-mail majordomo@gtf.org with "subscribe linux-via" in the @@ -27,7 +26,7 @@ body of the message. Thanks ------------------------------------------------------------------------ -Via for providing e-mail support, specs, and NDA's source code. +Via for providing e-mail support, specs, and NDA'd source code. MandrakeSoft for providing hacking time. @@ -40,15 +39,10 @@ Installation If the driver is being statically compiled into the kernel, no configuration should be necessary. -If the driver is being compiled as a module, generally two lines must +If the driver is being compiled as a module, generally one line must be added to your /etc/conf.modules (or /etc/modules.conf) file: - alias sound via82cxxx - options sb support=1 - -The second line is very important: it tells the required 'sb' module -not to load SoundBlaster support, but to instead let the Via driver -do so at a later time. + alias sound via82cxxx_audio @@ -63,8 +57,8 @@ Some architecture remains for multiple cards, feel free to submit a patch to clean some of that up. Ideally, No consideration for SMP, this chipset is not known to be found on -any SMP motherboards. However, this will change when we start handling -our own interrupts in "native mode." +any SMP motherboards. However, spin_locks must be used anyway in order +to handle interrupts correctly. GNU indent formatting options: -kr -i8 -pcs @@ -76,29 +70,17 @@ The following is an _incomplete_ list of motherboards supported by this audio driver. If your motherboard (or notebook) is not listed here, please e-mail the maintainer with details. - AOpen MX59 Pro (Apollo MVP4) + AOpen MX59 Pro + Compaq Presario 1247 -The Future +Random Developer Notes / Comments ------------------------------------------------------------------------ Via has graciously donated e-mail support and source code to help further the development of this driver. Their assistance has been invaluable in the design and coding of the next major version of this driver. -This audio chip supports a DirectSound(tm)-style hardware interface, -with a single 16-bit stereo input channel, and a single 16-bit stereo -output channel. Data is transferred to/from the hardware using -table-driven scatter-gather DMA buffers. - -Work is currently underway to support this "native mode" of the chip. -When complete, SoundBlaster legacy mode will be completely removed. -After a round of testing, this code will become version 2.0.0. - -Following the 2.0.0 release, the last major task to complete is -MIDI support. MPU-401 legacy support is available currently, but -not well tested at all. - The Via audio chip apparently provides a second PCM scatter-gather DMA channel just for FM data, but does not have a full hardware MIDI processor. I haven't put much thought towards a solution here, but it @@ -109,11 +91,15 @@ support altogether and using the FM PCM channel as a second (input? output?) General To-do List (patches/suggestions welcome) ------------------------------------------------------------------------ -Better docs +Recording support -Code review by sound guru(s) +mmap support -Native DSP audio driver using scatter-gather DMA, as described above +Other advanced ioctls + +Better docs + +Code review Native MIDI driver, as described above @@ -121,8 +107,35 @@ Native MIDI driver, as described above Known bugs (patches/suggestions welcome) ------------------------------------------------------------------------ -1) Two MIDI devices are loaded by the sound driver. Eliminate one of them. +1) Volume too low on many systems. Workaround: use mixer program +such as xmixer to increase volume. + +2) RealPlayer output very scratchy. + +3) Applications which attempt to open the sound device in read/write +mode (O_RDWR) will fail. This is incorrect OSS behavior, but since +this driver will eventually support recording as well as playback, +we will be able to (in the future) support even broken programs which +unconditionally use O_RDWR. + + + +Submitting a bug report +------------------------------------------------------------------------ +Describe the application you were using to play/record sound, and how +to reproduce the problem. + +Obtain the via-audio-diag diagnostics program from +http://gtf.org/garzik/drivers/via82cxxx/ and provide a dump of the +audio chip's registers while the problem is occurring. Sample command line: + ./via-audio-diag -aps > diag-output.txt + +Define "VIA_DEBUG" at the beginning of the driver, then capture and email +the kernel log output. This can be viewed in the system kernel log (if +enabled), or via the 'dmesg' program. + +If you wish to increase the size of the buffer displayed by 'dmesg', then +change the LOG_BUF_LEN macro at the top of linux/kernel/printk.c, recompile +your kernel, and pass the "-s <size>" option to 'dmesg'. + -2) Two mixer devices are loaded by the sound driver. Eliminate one of -them. At least one bug report says that SB mixer does not work at all, -only AC97 mixer. diff --git a/Documentation/usb/input.txt b/Documentation/usb/input.txt index ebf9058de..262c595e4 100644 --- a/Documentation/usb/input.txt +++ b/Documentation/usb/input.txt @@ -185,24 +185,28 @@ programs could use a more reasonable interface, for example evdev.c crw-r--r-- 1 root root 13, 33 Mar 29 00:41 mouse1 crw-r--r-- 1 root root 13, 34 Mar 29 00:41 mouse2 crw-r--r-- 1 root root 13, 35 Apr 1 10:50 mouse3 + ... + ... + crw-r--r-- 1 root root 13, 62 Apr 1 10:50 mouse30 + crw-r--r-- 1 root root 13, 63 Apr 1 10:50 mice -and so on, up to mouse31. Each is assigned to a single mouse or digitizer, -unless CONFIG_INPUT_MOUSEDEV_MIX is set. In that case all mice and -digitizers share a single character device, mouse0, and even when none are -connected, mouse0 is present. This is useful for hotplugging USB mice, so -that programs can open the device even when no mice are present. +Each 'mouse' device is assigned to a single mouse or digitizer, except the last +one - 'mice'. This single character device is shared by all mice and +digitizers, and even if none are connected, the device is present. This is +useful for hotplugging USB mice, so that programs can open the device even when +no mice are present. CONFIG_INPUT_MOUSEDEV_SCREEN_[XY] in the kernel configuration are the size of your screen (in pixels) in XFree86. This is needed if you want to use your digitizer in X, because it's movement is sent to X via a virtual PS/2 -mouse. +mouse. These values won't be used if you use a mouse only. Mousedev.c will generate either PS/2, ImPS/2 (microsoft intellimouse) or GenPS/2 (genius netmouse/netscroll) protocols, depending on what the program -wishes. You can set GPM and X to any of these. You'll need ImPS/2 if you -want to make use of a wheel on a USB mouse and GenPS/2 if you want to use -extra (up to 5) buttons. I'm not sure how much is GenPS/2 supported in X, -though. +reading the data wishes. You can set GPM and X to any of these. You'll need +ImPS/2 if you want to make use of a wheel on a USB mouse and GenPS/2 if you +want to use extra (up to 5) buttons. I'm not sure how much is GenPS/2 supported +in X, though. 3.2.3 joydev.c ~~~~~~~~~~~~~~ @@ -216,6 +220,7 @@ though. As soon as any USB joystick is connected, it can be accessed in crw-r--r-- 1 root root 13, 1 Apr 1 10:50 js1 crw-r--r-- 1 root root 13, 2 Apr 1 10:50 js2 crw-r--r-- 1 root root 13, 3 Apr 1 10:50 js3 + ... And so on up to js31. @@ -236,6 +241,7 @@ independent. crw-r--r-- 1 root root 13, 65 Apr 1 10:50 event1 crw-r--r-- 1 root root 13, 66 Apr 1 10:50 event2 crw-r--r-- 1 root root 13, 67 Apr 1 10:50 event3 + ... 3. Contacts ~~~~~~~~~~~ diff --git a/Documentation/usb/ov511.txt b/Documentation/usb/ov511.txt index b4c536ec1..58efa7ccf 100644 --- a/Documentation/usb/ov511.txt +++ b/Documentation/usb/ov511.txt @@ -6,8 +6,11 @@ Author: Mark McClelland Homepage: http://alpha.dyndns.org/ov511 NEW IN THIS VERSION: - o Support for OV511+ - o Support for OV7620 + o Improvements to sensor detection code + o Added "i2c_detect_tries" and "aperture" parameters + o proc filesystem status support + o read() fixed partially + o code cleanups and minor fixes INTRODUCTION: @@ -151,11 +154,13 @@ WORKING FEATURES: o Monochrome o Setting/getting of saturation, contrast and brightness (no hue yet; only works with OV7610, not the OV7620 or OV7620AE) + o proc status reporting EXPERIMENTAL FEATURES: o fix_rgb_offset: Sometimes works, but other times causes errors with xawtv and corrupted frames. o Snapshot mode (only works with some read() based apps; see below for more) + o read() support TODO: o Fix the noise / grainy image problem. @@ -180,6 +185,8 @@ TODO: o Get rid of the memory management functions (put them in videodev.c??) o Setting of contrast and brightness not working with 7620 o Driver/camera state save/restore for when USB supports suspend/resume + o Multiple cameras reportedly do not work simultaneously + o Problems with OHCI HOW TO CONTACT ME: diff --git a/Documentation/usb/scanner-hp-sane.txt b/Documentation/usb/scanner-hp-sane.txt index c47491765..25c36b7fe 100644 --- a/Documentation/usb/scanner-hp-sane.txt +++ b/Documentation/usb/scanner-hp-sane.txt @@ -1,13 +1,12 @@ Copyright (C) 1999, 2000 David E. Nelson -Mar. 23, 2000 +April 26, 2000 CHANGES -- Amended for Linux-2.3.40 +- Amended for Linux-2.3.99-pre6-3 - Updated for multiple scanner support - INTRODUCTION This document will hopefully provide enough info on how to get SANE @@ -15,9 +14,12 @@ working with a Hewlett Packard USB capable scanner using the USB interface. The majority of HP Scanners support the Scanner Control Language (SCL) which is both published by HP and supported by SANE. The only HP Scanners that I'm aware of that do not support SCL are the -4200C and the 3300C. All other HP scanners with USB interfaces should -work (4100C, 5200C, 6200C, and 6300C). Of course as HP releases new -scanners this information may change. +4200C ,3300C, and the PhotoSmart S20. All other HP scanners with USB +interfaces should work (4100C, 5200C, 6200C, and 6300C) as do models +that are derived from the models above. ie the 6350C which is a 6300C +with a transparency adaptor included with the scanner at time of +purchase. Of course as HP releases new scanners this information may +change. REQUIREMENTS @@ -37,9 +39,9 @@ At the time of this writing, version 0.83 was available. OK, I'VE INSTALLED SANE. SO WHAT DO I DO NOW? -NOTE: $INSTALL_DIR is the location where SANE is installed. It may -be /usr/local, /usr, /opt or somewhere else. If you don't know, ask -your system administrator. +NOTE: $INSTALL_DIR is the location where SANE is installed. It may be +/usr/local, /usr, /opt or somewhere else. If you don't know, ask your +system administrator. 1) Make sure that you have the libsane-hp.* libraries under the $INSTALL_DIR/lib/sane/ directory. If you don't, then the HP backend @@ -56,17 +58,18 @@ files: dll.conf, hp.conf. option connect-device NOTE: If you are using multiple scanners, make sure to have the correct -devince, ie /dev/usbscanner0. See scanner.txt for more info. +device, ie /dev/usbscanner0. See scanner.txt for more info. 3) You should now be able to use SANE (xscanimage or scanimage). Don't forget to read any relevant man pages regarding the usage of -SANE. If you have other entries uncommented in dll.conf, you may have -to specify the device to (x)scanimage. Again, `man` is your friend. -The xscanimage (1) man page has info on how to get 'The Gimp' to work -with xscanimage. Note that Gimp support must be compiled into SANE -for it work. If you are dealing with a RedHat system, this means that -you'll also need to install the gimp-devel rpm package. +SANE. If you have other entries uncommented in 'dll.conf', you may +have to specify the device to (x)scanimage. Again, `man` is your +friend. The xscanimage (1) man page has info on how to get 'The Gimp' +to work with xscanimage. Note that Gimp support must be compiled into +SANE for it to work. If you are dealing with a RedHat system, this +means that you'll also need to install the gimp-devel rpm package +prior to compiling SANE. NOTE: The issues regarding core dumping by (x)scanimage have (or seem to be thus far) been resolved with version 0.2+ of the USB scanner diff --git a/Documentation/usb/scanner.txt b/Documentation/usb/scanner.txt index a750e191d..e800b37e5 100644 --- a/Documentation/usb/scanner.txt +++ b/Documentation/usb/scanner.txt @@ -1,25 +1,26 @@ Copyright (C) 1999, 2000 David E. Nelson -Mar. 23, 2000 +April 26, 2000 CHANGES -- Amended for linux-2.3.40 +- Amended for linux-2.3.99-pre6-3 - Appended hp_scan.c to end of this README - Removed most references to HP - Updated uhci/ohci host controller info - Updated support for multiple scanner support - Updated supported scanners list - +- Updated usbdevfs info +- Spellcheck OVERVIEW -This README will address issues regarding how to configure the kernel +This README addresses issues regarding how to configure the kernel to access a USB scanner. Although the driver was originally conceived for USB HP scanners, it's general enough so that it can be used with other scanners. Also, one can now pass the USB Vendor and Product ID's using module parameters for unknown scanners. Refer to the -document scanner_hp_sane.txt for guidance on how to configure SANE to +document scanner-hp-sane.txt for guidance on how to configure SANE to use a USB HP Scanner. @@ -41,11 +42,11 @@ more information on accomplishing this. A Linux kernel with USB Scanner support enabled. 'lspci' which is only needed to determine the type of USB hardware -available in your machine. +available/installed in your machine. CONFIGURATION -Using `lspci -v`, determine the type of USB hardware available. +Using `lspci -v`, determine the type of USB hardware available/installed. If you see something like: @@ -68,7 +69,10 @@ kernel, select 'Support for USB', 'OHCI/UHCI' depending on your hardware (determined from the steps above), 'USB Scanner support', and 'Preliminary USB device filesystem'. Compile and install the modules (you may need to execute `depmod -a` to update the module -dependencies). Testing was performed only as modules, YMMV. +dependencies). If any of the USB sections were compiled into the +kernel, a reboot is necessary. NOTE: Updating the boot disk with +'lilo' may also be required. Testing was performed only as modules, +YMMV. Beginning with version 0.4 of the driver, up to 16 scanners can be connected/used simultaneously. If you intend to use more than @@ -82,14 +86,15 @@ one scanner at a time: `mknod /dev/usb/scanner15 180 63` -If you forsee using only one scanner: +If you foresee using only one scanner it is best to: `mknod /dev/usbscanner0 c 180 48` `ln -s /dev/usbscanner0 /dev/usbscanner` Set appropriate permissions for /dev/usbscanner[0-15] (don't forget about group and world permissions). Both read and write permissions -are required for proper operation. +are required for proper operation. For example: + `chmod 666 /dev/usbscanner0` Load the appropriate modules (if compiled as modules): @@ -108,12 +113,23 @@ be used to test the scanner device if it's an HP scanner that supports SCL (Scanner Control Language). Known HP scanner that support SCL are the 4100, 5200, 6200, the 6300 -- note that the 4200 is *not* supported since it does not understand SCL; it's also strongly -suspected that the 3300 is not SCL compliant. Hp_scan.c's purpose is -to test the driver without having to retrieve/configure SANE. -Hp_scan.c will scan the entire bed and put the output into a file -called 'out.dat' in the current directory. The data in the file is -raw data so it's not very useful for imaging. - +suspected that the 3300 and the PhotoSmart S20 are not SCL compliant. +Hp_scan.c's purpose is to test the driver without having to +retrieve/configure SANE. Hp_scan.c will scan the entire bed and put +the output into a file called 'out.dat' in the current directory. The +data in the file is raw data so it's not very useful for imaging. + +MESSAGES + +On occassion the message 'usb_control/bulk_msg: timeout' or something +similar will appear in '/var/adm/messages' or on the console or both, +depending on how your system is configured. This is a side effect +that scanners are sometimes very slow at warming up and/or +initialiazing. In most cases, however, only several of these messages +should appear and is generally considered to be normal. If you see +a message of the type 'excessive NAK's received' then this should +be considered abnormal and generally indicates that the USB system is +unable to communicate with the scanner for some particular reason. SUPPORTED SCANNERS @@ -125,72 +141,97 @@ support the listed USB products. At the time of this writing, the following scanners were supported by scanner.c: - Acer - - Prisa AcerScan 620U - - Agfa - - SnapScan 1212U, SnapScan Touch - - Genius - - ColorPage Vivid Pro - - Hewlett Packard - - 3300, 4100, 4200, 5200, 6200, 6300, PhotoSmart S20 - - Microtek - - ScanMaker X6-X6U, Phantom 336CX - C3, Phantom C6, ScanMaker V6USL, - ScanMaker V6UL - SpicyU - - Mustek + Acer + Prisa Acerscan 620U & 640U (!) + Prisa AcerScan 620U (!) + Agfa + SnapScan 1212U + Another SnapScan 1212U (?) + SnapScan Touch + Colorado -- See Primax/Colorado below + Epson -- See Seiko/Epson below + Genius + ColorPage-Vivid Pro + Hewlett Packard + 3300C + 4100C + 4200C + PhotoSmart S20 + 5200C + 6200C + 6300C + Microtek + ScanMaker X6 - X6U + Phantom 336CX - C3 + Phantom 336CX - C3 #2 + Phantom C6 + ScanMaker V6USL + ScanMaker V6USL #2 + ScanMaker V6UL - SpicyU + Mustek + 1200 CU + Primax/Colorado + G2-300 #1 + G2-600 #1 + G2E-300 #1 + ReadyScan 636i + G2-300 #2 + G2-600 #2 + G2E-300 #2 + G2E-600 + Colorado USB 9600 + Colorado USB 19200 + Colorado 600u + Colorado 1200u + Seiko/Epson Corp. + Perfection 636U and 636Photo + Perfection 610 + Perfection 1200U and 1200Photo + Umax + Astra 1220U + Astra 1236U + Astra 2000U + Astra 2200U + Visioneer + OneTouch 5300 + OneTouch 7600 duplicate ID (!) + 6100 - 1200 CU - Primax/Colorado - - G2-300, G2-600, G2E-300, G2E-600, ReadyScan 636i, Colorado USB - 19200, Colorado 600u, Colorado 1200u - - Seiko/Epson - - Perfection Perfection 610, Perfection 636U/636Photo, Perfection - 1200U/1200Photo - - Umax +MODULE PARAMETERS - Astra 1220U, 1236U, 2000U +If you have a device that you wish to experiment with or try using +this driver with, but the Vendor and Product ID's are not coded in, +don't despair. If the driver was compiled as a module, you can pass +options to the driver. Simply add - Visioneer + options scanner vendor=0x#### product=0x**** - OneTouch 5300, OneTouch 7600, 6100, +to the /etc/modules.conf file replacing the #'s and the *'s with the +correct ID's. The ID's can be retrieved from the messages file or +using `cat /proc/bus/usb/devices`. Note that USB /proc support must be +enabled during kernel configuration. If the 'scanner' module is +already loaded into memory, it must be reloaded for the module +parameters to take effect. In essence, `rmmod scanner; modprobe +scanner` must be performed. +**NOTE**: In later kernels (2.3.38+), a new filesystem was introduced, +usbdevfs. To mount the filesystem, issue the command (as root): - User Specified. See MODULE PARAMETERS for details. + mount -t usbdevfs /proc/bus/usb /proc/bus/usb +An alternative and more permanent method would be to add -MODULE PARAMETERS + none /proc/bus/usb usbdevfs defaults 0 0 -If you have a device that you wish to experiment with or try using -this driver with, but the Vendor and Product ID's are not coded in, -don't despair. If the driver was compiled as a module, you can pass -options to the driver. Simply add 'options scanner vendor=0x#### -product=0x****' to the conf.modules/modules.conf file replacing the -#'s and the *'s with the correct ID's. The ID's can be retrieved from -the messages file or using `cat /proc/bus/usb/devices` if USB /proc -support was selected during kernel configuration. **NOTE**:In later -kernels (2.3.38+), a new filesystem was introduced, usbdevfs. To -mount the filesystem, issue the command `mount -t usbdevfs -/proc/bus/usb /proc/bus/usb`. You can then issue ` cat -/proc/bus/usb/devices` to extract USB device information. +to /etc/fstab. This will mount usbdevfs at each reboot. You can then +issue `cat /proc/bus/usb/devices` to extract USB device information. BUGS -If you encounter any problems feel free to drop me an email. +Just look at the list of fixes in the source files. So, if you +encounter any problems feel free to drop me an email. David /\/elson dnelson@jump.net diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt index 1ea46bbaa..193ab6ddc 100644 --- a/Documentation/usb/usb-serial.txt +++ b/Documentation/usb/usb-serial.txt @@ -10,30 +10,30 @@ INTRODUCTION CONFIGURATION - Currently the driver can handle up to 16 different serial interfaces at - one time. Once more of the drivers become stable, this number will be - increased to the full 256. + Currently the driver can handle up to 256 different serial interfaces at + one time. - The major number that the driver uses is 188 so to use the driver, - create the following nodes: + If you are not using devfs: + The major number that the driver uses is 188 so to use the driver, + create the following nodes: mknod /dev/ttyUSB0 c 188 0 mknod /dev/ttyUSB1 c 188 1 mknod /dev/ttyUSB2 c 188 2 mknod /dev/ttyUSB3 c 188 3 - mknod /dev/ttyUSB4 c 188 4 - mknod /dev/ttyUSB5 c 188 5 - mknod /dev/ttyUSB6 c 188 6 - mknod /dev/ttyUSB7 c 188 7 - mknod /dev/ttyUSB8 c 188 8 - mknod /dev/ttyUSB9 c 188 9 - mknod /dev/ttyUSB10 c 188 10 - mknod /dev/ttyUSB11 c 188 11 - mknod /dev/ttyUSB12 c 188 12 - mknod /dev/ttyUSB13 c 188 13 - mknod /dev/ttyUSB14 c 188 14 - mknod /dev/ttyUSB15 c 188 15 - mknod /dev/ttyUSB16 c 188 16 - + . + . + . + mknod /dev/ttyUSB254 c 188 254 + mknod /dev/ttyUSB255 c 188 255 + + If you are using devfs: + The devices supported by this driver will show up as + /dev/usb/tts/{0,1,...} + + When the device is connected and recognized by the driver, the driver + will print to the system log, which node(s) the device has been bound + to. + SPECIFIC DEVICES SUPPORTED @@ -45,8 +45,9 @@ ConnectTech WhiteHEAT 4 port converter being fully supported. Current status: - The device's firmware is downloaded on connection, but the use of a - special Anchor Chips extension is currently giving me problems. + The device's firmware is downloaded on connection, the new firmware + runs properly and all four ports are successfuly recognized and connected. + Now data flow needs to be implemented properly. This driver is not fully operational. @@ -61,7 +62,9 @@ Current status: When the device is connected, try talking to it on the second port (this is usually /dev/ttyUSB1 if you do not have any other usb-serial - devices in the system.) + devices in the system.) The system log should tell you which port is + the port to use for the HotSync transfer. The "Generic" port can be used + for other device communication, such as a PPP link. There is a webpage and mailing lists for this portion of the driver at: http://usbvisor.sourceforge.net/ @@ -91,6 +94,19 @@ Current status: O_NONBLOCK, select() +FTDI Single Port Serial Driver + + This is a single port DB-25 serial adapter. More information about this + device and the Linux driver can be found at: + http://reality.sgi.com/bryder_wellington/ftdi_sio/ + + +ZyXEL omni.net lcd plus ISDN TA + + This is an ISDN TA. Please report both successes and troubles to the + author at omninet@kroah.com + + Generic Serial driver If your device is not one of the above listed devices, compatible with |