Loading .mailmap +2 −0 Original line number Diff line number Diff line Loading @@ -67,6 +67,8 @@ Koushik <raghavendra.koushik@neterion.com> Leonid I Ananiev <leonid.i.ananiev@intel.com> Linas Vepstas <linas@austin.ibm.com> Matthieu CASTET <castet.matthieu@free.fr> Michael Buesch <mb@bu3sch.de> Michael Buesch <mbuesch@freenet.de> Michel Dänzer <michel@tungstengraphics.com> Mitesh shah <mshah@teja.com> Morten Welinder <terra@gnome.org> Loading CREDITS +18 −4 Original line number Diff line number Diff line Loading @@ -317,6 +317,12 @@ S: 2322 37th Ave SW S: Seattle, Washington 98126-2010 S: USA N: Johannes Berg E: johannes@sipsolutions.net W: http://johannes.sipsolutions.net/ P: 1024D/9AB78CA5 AD02 0176 4E29 C137 1DF6 08D2 FC44 CF86 9AB7 8CA5 D: powerpc & 802.11 hacker N: Stephen R. van den Berg (AKA BuGless) E: berg@pool.informatik.rwth-aachen.de D: General kernel, gcc, and libc hacker Loading Loading @@ -2286,14 +2292,14 @@ S: D-90453 Nuernberg S: Germany N: Arnaldo Carvalho de Melo E: acme@mandriva.com E: acme@ghostprotocols.net E: arnaldo.melo@gmail.com E: acme@redhat.com W: http://oops.ghostprotocols.net:81/blog/ P: 1024D/9224DF01 D5DF E3BB E3C8 BCBB F8AD 841A B6AB 4681 9224 DF01 D: IPX, LLC, DCCP, cyc2x, wl3501_cs, net/ hacks S: Mandriva S: R. Tocantins, 89 - Cristo Rei S: 80050-430 - Curitiba - Paran S: R. Braslio Itiber, 4270/1010 - gua Verde S: 80240-060 - Curitiba - Paran S: Brazil N: Karsten Merker Loading Loading @@ -3295,6 +3301,14 @@ S: 12725 SW Millikan Way, Suite 400 S: Beaverton, Oregon 97005 S: USA N: Li Yang E: leoli@freescale.com D: Freescale Highspeed USB device driver D: Freescale QE SoC support and Ethernet driver S: B-1206 Jingmao Guojigongyu S: 16 Baliqiao Nanjie, Beijing 101100 S: People's Repulic of China N: Marcelo Tosatti E: marcelo@kvack.org D: v2.4 kernel maintainer Loading Documentation/ABI/testing/sysfs-bus-usb 0 → 100644 +41 −0 Original line number Diff line number Diff line What: /sys/bus/usb/devices/.../power/autosuspend Date: March 2007 KernelVersion: 2.6.21 Contact: Alan Stern <stern@rowland.harvard.edu> Description: Each USB device directory will contain a file named power/autosuspend. This file holds the time (in seconds) the device must be idle before it will be autosuspended. 0 means the device will be autosuspended as soon as possible. Negative values will prevent the device from being autosuspended at all, and writing a negative value will resume the device if it is already suspended. The autosuspend delay for newly-created devices is set to the value of the usbcore.autosuspend module parameter. What: /sys/bus/usb/devices/.../power/level Date: March 2007 KernelVersion: 2.6.21 Contact: Alan Stern <stern@rowland.harvard.edu> Description: Each USB device directory will contain a file named power/level. This file holds a power-level setting for the device, one of "on", "auto", or "suspend". "on" means that the device is not allowed to autosuspend, although normal suspends for system sleep will still be honored. "auto" means the device will autosuspend and autoresume in the usual manner, according to the capabilities of its driver. "suspend" means the device is forced into a suspended state and it will not autoresume in response to I/O requests. However remote-wakeup requests from the device may still be enabled (the remote-wakeup setting is controlled separately by the power/wakeup attribute). During normal use, devices should be left in the "auto" level. The other levels are meant for administrative uses. If you want to suspend a device immediately but leave it free to wake up in response to I/O requests, you should write "0" to power/autosuspend. Documentation/feature-removal-schedule.txt +31 −30 Original line number Diff line number Diff line Loading @@ -6,6 +6,18 @@ be removed from this file. --------------------------- What: V4L2 VIDIOC_G_MPEGCOMP and VIDIOC_S_MPEGCOMP When: October 2007 Why: Broken attempt to set MPEG compression parameters. These ioctls are not able to implement the wide variety of parameters that can be set by hardware MPEG encoders. A new MPEG control mechanism was created in kernel 2.6.18 that replaces these ioctls. See the V4L2 specification (section 1.9: Extended controls) for more information on this topic. Who: Hans Verkuil <hverkuil@xs4all.nl> and Mauro Carvalho Chehab <mchehab@infradead.org> --------------------------- What: /sys/devices/.../power/state dev->power.power_state dpm_runtime_{suspend,resume)() Loading Loading @@ -134,15 +146,6 @@ Who: Arjan van de Ven <arjan@linux.intel.com> --------------------------- What: mount/umount uevents When: February 2007 Why: These events are not correct, and do not properly let userspace know when a file system has been mounted or unmounted. Userspace should poll the /proc/mounts file instead to detect this properly. Who: Greg Kroah-Hartman <gregkh@suse.de> --------------------------- What: USB driver API moves to EXPORT_SYMBOL_GPL When: February 2008 Files: include/linux/usb.h, drivers/usb/core/driver.c Loading Loading @@ -211,15 +214,6 @@ Who: Adrian Bunk <bunk@stusta.de> --------------------------- What: IPv4 only connection tracking/NAT/helpers When: 2.6.22 Why: The new layer 3 independant connection tracking replaces the old IPv4 only version. After some stabilization of the new code the old one will be removed. Who: Patrick McHardy <kaber@trash.net> --------------------------- What: ACPI hooks (X86_SPEEDSTEP_CENTRINO_ACPI) in speedstep-centrino driver When: December 2006 Why: Speedstep-centrino driver with ACPI hooks and acpi-cpufreq driver are Loading Loading @@ -294,18 +288,6 @@ Who: Richard Purdie <rpurdie@rpsys.net> --------------------------- What: Wireless extensions over netlink (CONFIG_NET_WIRELESS_RTNETLINK) When: with the merge of wireless-dev, 2.6.22 or later Why: The option/code is * not enabled on most kernels * not required by any userspace tools (except an experimental one, and even there only for some parts, others use ioctl) * pointless since wext is no longer evolving and the ioctl interface needs to be kept Who: Johannes Berg <johannes@sipsolutions.net> --------------------------- What: i8xx_tco watchdog driver When: in 2.6.22 Why: the i8xx_tco watchdog driver has been replaced by the iTCO_wdt Loading @@ -313,3 +295,22 @@ Why: the i8xx_tco watchdog driver has been replaced by the iTCO_wdt Who: Wim Van Sebroeck <wim@iguana.be> --------------------------- What: Multipath cached routing support in ipv4 When: in 2.6.23 Why: Code was merged, then submitter immediately disappeared leaving us with no maintainer and lots of bugs. The code should not have been merged in the first place, and many aspects of it's implementation are blocking more critical core networking development. It's marked EXPERIMENTAL and no distribution enables it because it cause obscure crashes due to unfixable bugs (interfaces don't return errors so memory allocation can't be handled, calling contexts of these interfaces make handling errors impossible too because they get called after we've totally commited to creating a route object, for example). This problem has existed for years and no forward progress has ever been made, and nobody steps up to try and salvage this code, so we're going to finally just get rid of it. Who: David S. Miller <davem@davemloft.net> --------------------------- Documentation/filesystems/afs.txt +154 −60 Original line number Diff line number Diff line ==================== kAFS: AFS FILESYSTEM ==================== ABOUT ===== Contents: - Overview. - Usage. - Mountpoints. - Proc filesystem. - The cell database. - Security. - Examples. ======== OVERVIEW ======== This filesystem provides a fairly simple AFS filesystem driver. It is under development and only provides very basic facilities. It does not yet support the following AFS features: This filesystem provides a fairly simple secure AFS filesystem driver. It is under development and does not yet provide the full feature set. The features it does support include: (*) Security (currently only AFS kaserver and KerberosIV tickets). (*) File reading. (*) Automounting. It does not yet support the following AFS features: (*) Write support. (*) Communications security. (*) Local caching. (*) pioctl() system call. (*) Automatic mounting of embedded mountpoints. =========== COMPILATION =========== The filesystem should be enabled by turning on the kernel configuration options: CONFIG_AF_RXRPC - The RxRPC protocol transport CONFIG_RXKAD - The RxRPC Kerberos security handler CONFIG_AFS - The AFS filesystem Additionally, the following can be turned on to aid debugging: CONFIG_AF_RXRPC_DEBUG - Permit AF_RXRPC debugging to be enabled CONFIG_AFS_DEBUG - Permit AFS debugging to be enabled They permit the debugging messages to be turned on dynamically by manipulating the masks in the following files: /sys/module/af_rxrpc/parameters/debug /sys/module/afs/parameters/debug ===== USAGE ===== When inserting the driver modules the root cell must be specified along with a list of volume location server IP addresses: insmod rxrpc.o insmod af_rxrpc.o insmod rxkad.o insmod kafs.o rootcell=cambridge.redhat.com:172.16.18.73:172.16.18.91 The first module is a driver for the RxRPC remote operation protocol, and the second is the actual filesystem driver for the AFS filesystem. The first module is the AF_RXRPC network protocol driver. This provides the RxRPC remote operation protocol and may also be accessed from userspace. See: Documentation/networking/rxrpc.txt The second module is the kerberos RxRPC security driver, and the third module is the actual filesystem driver for the AFS filesystem. Once the module has been loaded, more modules can be added by the following procedure: Loading @@ -33,7 +84,7 @@ procedure: echo add grand.central.org 18.7.14.88:128.2.191.224 >/proc/fs/afs/cells Where the parameters to the "add" command are the name of a cell and a list of volume location servers within that cell. volume location servers within that cell, with the latter separated by colons. Filesystems can be mounted anywhere by commands similar to the following: Loading @@ -42,11 +93,6 @@ Filesystems can be mounted anywhere by commands similar to the following: mount -t afs "#root.afs." /afs mount -t afs "#root.cell." /afs/cambridge NB: When using this on Linux 2.4, the mount command has to be different, since the filesystem doesn't have access to the device name argument: mount -t afs none /afs -ovol="#root.afs." Where the initial character is either a hash or a percent symbol depending on whether you definitely want a R/W volume (hash) or whether you'd prefer a R/O volume, but are willing to use a R/W volume instead (percent). Loading @@ -60,55 +106,66 @@ named volume will be looked up in the cell specified during insmod. Additional cells can be added through /proc (see later section). =========== MOUNTPOINTS =========== AFS has a concept of mountpoints. These are specially formatted symbolic links (of the same form as the "device name" passed to mount). kAFS presents these to the user as directories that have special properties: AFS has a concept of mountpoints. In AFS terms, these are specially formatted symbolic links (of the same form as the "device name" passed to mount). kAFS presents these to the user as directories that have a follow-link capability (ie: symbolic link semantics). If anyone attempts to access them, they will automatically cause the target volume to be mounted (if possible) on that site. (*) They cannot be listed. Running a program like "ls" on them will incur an EREMOTE error (Object is remote). Automatically mounted filesystems will be automatically unmounted approximately twenty minutes after they were last used. Alternatively they can be unmounted directly with the umount() system call. (*) Other objects can't be looked up inside of them. This also incurs an EREMOTE error. Manually unmounting an AFS volume will cause any idle submounts upon it to be culled first. If all are culled, then the requested volume will also be unmounted, otherwise error EBUSY will be returned. (*) They can be queried with the readlink() system call, which will return the name of the mountpoint to which they point. The "readlink" program will also work. This can be used by the administrator to attempt to unmount the whole AFS tree mounted on /afs in one go by doing: (*) They can be mounted on (which symbolic links can't). umount /afs =============== PROC FILESYSTEM =============== The rxrpc module creates a number of files in various places in the /proc filesystem: (*) Firstly, some information files are made available in a directory called "/proc/net/rxrpc/". These list the extant transport endpoint, peer, connection and call records. (*) Secondly, some control files are made available in a directory called "/proc/sys/rxrpc/". Currently, all these files can be used for is to turn on various levels of tracing. The AFS modules creates a "/proc/fs/afs/" directory and populates it: (*) A "cells" file that lists cells currently known to the afs module. (*) A "cells" file that lists cells currently known to the afs module and their usage counts: [root@andromeda ~]# cat /proc/fs/afs/cells USE NAME 3 cambridge.redhat.com (*) A directory per cell that contains files that list volume location servers, volumes, and active servers known within that cell. [root@andromeda ~]# cat /proc/fs/afs/cambridge.redhat.com/servers USE ADDR STATE 4 172.16.18.91 0 [root@andromeda ~]# cat /proc/fs/afs/cambridge.redhat.com/vlservers ADDRESS 172.16.18.91 [root@andromeda ~]# cat /proc/fs/afs/cambridge.redhat.com/volumes USE STT VLID[0] VLID[1] VLID[2] NAME 1 Val 20000000 20000001 20000002 root.afs ================= THE CELL DATABASE ================= The filesystem maintains an internal database of all the cells it knows and the IP addresses of the volume location servers for those cells. The cell to which the computer belongs is added to the database when insmod is performed by the "rootcell=" argument. The filesystem maintains an internal database of all the cells it knows and the IP addresses of the volume location servers for those cells. The cell to which the system belongs is added to the database when insmod is performed by the "rootcell=" argument or, if compiled in, using a "kafs.rootcell=" argument on the kernel command line. Further cells can be added by commands similar to the following: Loading @@ -118,6 +175,50 @@ Further cells can be added by commands similar to the following: No other cell database operations are available at this time. ======== SECURITY ======== Secure operations are initiated by acquiring a key using the klog program. A very primitive klog program is available at: http://people.redhat.com/~dhowells/rxrpc/klog.c This should be compiled by: make klog LDLIBS="-lcrypto -lcrypt -lkrb4 -lkeyutils" And then run as: ./klog Assuming it's successful, this adds a key of type RxRPC, named for the service and cell, eg: "afs@<cellname>". This can be viewed with the keyctl program or by cat'ing /proc/keys: [root@andromeda ~]# keyctl show Session Keyring -3 --alswrv 0 0 keyring: _ses.3268 2 --alswrv 0 0 \_ keyring: _uid.0 111416553 --als--v 0 0 \_ rxrpc: afs@CAMBRIDGE.REDHAT.COM Currently the username, realm, password and proposed ticket lifetime are compiled in to the program. It is not required to acquire a key before using AFS facilities, but if one is not acquired then all operations will be governed by the anonymous user parts of the ACLs. If a key is acquired, then all AFS operations, including mounts and automounts, made by a possessor of that key will be secured with that key. If a file is opened with a particular key and then the file descriptor is passed to a process that doesn't have that key (perhaps over an AF_UNIX socket), then the operations on the file will be made with key that was used to open the file. ======== EXAMPLES ======== Loading @@ -125,8 +226,9 @@ Here's what I use to test this. Some of the names and IP addresses are local to my internal DNS. My "root.afs" partition has a mount point within it for some public volumes volumes. insmod -S /tmp/rxrpc.o insmod -S /tmp/kafs.o rootcell=cambridge.redhat.com:172.16.18.73:172.16.18.91 insmod /tmp/rxrpc.o insmod /tmp/rxkad.o insmod /tmp/kafs.o rootcell=cambridge.redhat.com:172.16.18.91 mount -t afs \%root.afs. /afs mount -t afs \%cambridge.redhat.com:root.cell. /afs/cambridge.redhat.com/ Loading @@ -141,15 +243,7 @@ mount -t afs "#grand.central.org:root.service." /afs/grand.central.org/service mount -t afs "#grand.central.org:root.software." /afs/grand.central.org/software mount -t afs "#grand.central.org:root.user." /afs/grand.central.org/user umount /afs/grand.central.org/user umount /afs/grand.central.org/software umount /afs/grand.central.org/service umount /afs/grand.central.org/project umount /afs/grand.central.org/doc umount /afs/grand.central.org/contrib umount /afs/grand.central.org/archive umount /afs/grand.central.org umount /afs/cambridge.redhat.com umount /afs rmmod kafs rmmod rxkad rmmod rxrpc Loading
.mailmap +2 −0 Original line number Diff line number Diff line Loading @@ -67,6 +67,8 @@ Koushik <raghavendra.koushik@neterion.com> Leonid I Ananiev <leonid.i.ananiev@intel.com> Linas Vepstas <linas@austin.ibm.com> Matthieu CASTET <castet.matthieu@free.fr> Michael Buesch <mb@bu3sch.de> Michael Buesch <mbuesch@freenet.de> Michel Dänzer <michel@tungstengraphics.com> Mitesh shah <mshah@teja.com> Morten Welinder <terra@gnome.org> Loading
CREDITS +18 −4 Original line number Diff line number Diff line Loading @@ -317,6 +317,12 @@ S: 2322 37th Ave SW S: Seattle, Washington 98126-2010 S: USA N: Johannes Berg E: johannes@sipsolutions.net W: http://johannes.sipsolutions.net/ P: 1024D/9AB78CA5 AD02 0176 4E29 C137 1DF6 08D2 FC44 CF86 9AB7 8CA5 D: powerpc & 802.11 hacker N: Stephen R. van den Berg (AKA BuGless) E: berg@pool.informatik.rwth-aachen.de D: General kernel, gcc, and libc hacker Loading Loading @@ -2286,14 +2292,14 @@ S: D-90453 Nuernberg S: Germany N: Arnaldo Carvalho de Melo E: acme@mandriva.com E: acme@ghostprotocols.net E: arnaldo.melo@gmail.com E: acme@redhat.com W: http://oops.ghostprotocols.net:81/blog/ P: 1024D/9224DF01 D5DF E3BB E3C8 BCBB F8AD 841A B6AB 4681 9224 DF01 D: IPX, LLC, DCCP, cyc2x, wl3501_cs, net/ hacks S: Mandriva S: R. Tocantins, 89 - Cristo Rei S: 80050-430 - Curitiba - Paran S: R. Braslio Itiber, 4270/1010 - gua Verde S: 80240-060 - Curitiba - Paran S: Brazil N: Karsten Merker Loading Loading @@ -3295,6 +3301,14 @@ S: 12725 SW Millikan Way, Suite 400 S: Beaverton, Oregon 97005 S: USA N: Li Yang E: leoli@freescale.com D: Freescale Highspeed USB device driver D: Freescale QE SoC support and Ethernet driver S: B-1206 Jingmao Guojigongyu S: 16 Baliqiao Nanjie, Beijing 101100 S: People's Repulic of China N: Marcelo Tosatti E: marcelo@kvack.org D: v2.4 kernel maintainer Loading
Documentation/ABI/testing/sysfs-bus-usb 0 → 100644 +41 −0 Original line number Diff line number Diff line What: /sys/bus/usb/devices/.../power/autosuspend Date: March 2007 KernelVersion: 2.6.21 Contact: Alan Stern <stern@rowland.harvard.edu> Description: Each USB device directory will contain a file named power/autosuspend. This file holds the time (in seconds) the device must be idle before it will be autosuspended. 0 means the device will be autosuspended as soon as possible. Negative values will prevent the device from being autosuspended at all, and writing a negative value will resume the device if it is already suspended. The autosuspend delay for newly-created devices is set to the value of the usbcore.autosuspend module parameter. What: /sys/bus/usb/devices/.../power/level Date: March 2007 KernelVersion: 2.6.21 Contact: Alan Stern <stern@rowland.harvard.edu> Description: Each USB device directory will contain a file named power/level. This file holds a power-level setting for the device, one of "on", "auto", or "suspend". "on" means that the device is not allowed to autosuspend, although normal suspends for system sleep will still be honored. "auto" means the device will autosuspend and autoresume in the usual manner, according to the capabilities of its driver. "suspend" means the device is forced into a suspended state and it will not autoresume in response to I/O requests. However remote-wakeup requests from the device may still be enabled (the remote-wakeup setting is controlled separately by the power/wakeup attribute). During normal use, devices should be left in the "auto" level. The other levels are meant for administrative uses. If you want to suspend a device immediately but leave it free to wake up in response to I/O requests, you should write "0" to power/autosuspend.
Documentation/feature-removal-schedule.txt +31 −30 Original line number Diff line number Diff line Loading @@ -6,6 +6,18 @@ be removed from this file. --------------------------- What: V4L2 VIDIOC_G_MPEGCOMP and VIDIOC_S_MPEGCOMP When: October 2007 Why: Broken attempt to set MPEG compression parameters. These ioctls are not able to implement the wide variety of parameters that can be set by hardware MPEG encoders. A new MPEG control mechanism was created in kernel 2.6.18 that replaces these ioctls. See the V4L2 specification (section 1.9: Extended controls) for more information on this topic. Who: Hans Verkuil <hverkuil@xs4all.nl> and Mauro Carvalho Chehab <mchehab@infradead.org> --------------------------- What: /sys/devices/.../power/state dev->power.power_state dpm_runtime_{suspend,resume)() Loading Loading @@ -134,15 +146,6 @@ Who: Arjan van de Ven <arjan@linux.intel.com> --------------------------- What: mount/umount uevents When: February 2007 Why: These events are not correct, and do not properly let userspace know when a file system has been mounted or unmounted. Userspace should poll the /proc/mounts file instead to detect this properly. Who: Greg Kroah-Hartman <gregkh@suse.de> --------------------------- What: USB driver API moves to EXPORT_SYMBOL_GPL When: February 2008 Files: include/linux/usb.h, drivers/usb/core/driver.c Loading Loading @@ -211,15 +214,6 @@ Who: Adrian Bunk <bunk@stusta.de> --------------------------- What: IPv4 only connection tracking/NAT/helpers When: 2.6.22 Why: The new layer 3 independant connection tracking replaces the old IPv4 only version. After some stabilization of the new code the old one will be removed. Who: Patrick McHardy <kaber@trash.net> --------------------------- What: ACPI hooks (X86_SPEEDSTEP_CENTRINO_ACPI) in speedstep-centrino driver When: December 2006 Why: Speedstep-centrino driver with ACPI hooks and acpi-cpufreq driver are Loading Loading @@ -294,18 +288,6 @@ Who: Richard Purdie <rpurdie@rpsys.net> --------------------------- What: Wireless extensions over netlink (CONFIG_NET_WIRELESS_RTNETLINK) When: with the merge of wireless-dev, 2.6.22 or later Why: The option/code is * not enabled on most kernels * not required by any userspace tools (except an experimental one, and even there only for some parts, others use ioctl) * pointless since wext is no longer evolving and the ioctl interface needs to be kept Who: Johannes Berg <johannes@sipsolutions.net> --------------------------- What: i8xx_tco watchdog driver When: in 2.6.22 Why: the i8xx_tco watchdog driver has been replaced by the iTCO_wdt Loading @@ -313,3 +295,22 @@ Why: the i8xx_tco watchdog driver has been replaced by the iTCO_wdt Who: Wim Van Sebroeck <wim@iguana.be> --------------------------- What: Multipath cached routing support in ipv4 When: in 2.6.23 Why: Code was merged, then submitter immediately disappeared leaving us with no maintainer and lots of bugs. The code should not have been merged in the first place, and many aspects of it's implementation are blocking more critical core networking development. It's marked EXPERIMENTAL and no distribution enables it because it cause obscure crashes due to unfixable bugs (interfaces don't return errors so memory allocation can't be handled, calling contexts of these interfaces make handling errors impossible too because they get called after we've totally commited to creating a route object, for example). This problem has existed for years and no forward progress has ever been made, and nobody steps up to try and salvage this code, so we're going to finally just get rid of it. Who: David S. Miller <davem@davemloft.net> ---------------------------
Documentation/filesystems/afs.txt +154 −60 Original line number Diff line number Diff line ==================== kAFS: AFS FILESYSTEM ==================== ABOUT ===== Contents: - Overview. - Usage. - Mountpoints. - Proc filesystem. - The cell database. - Security. - Examples. ======== OVERVIEW ======== This filesystem provides a fairly simple AFS filesystem driver. It is under development and only provides very basic facilities. It does not yet support the following AFS features: This filesystem provides a fairly simple secure AFS filesystem driver. It is under development and does not yet provide the full feature set. The features it does support include: (*) Security (currently only AFS kaserver and KerberosIV tickets). (*) File reading. (*) Automounting. It does not yet support the following AFS features: (*) Write support. (*) Communications security. (*) Local caching. (*) pioctl() system call. (*) Automatic mounting of embedded mountpoints. =========== COMPILATION =========== The filesystem should be enabled by turning on the kernel configuration options: CONFIG_AF_RXRPC - The RxRPC protocol transport CONFIG_RXKAD - The RxRPC Kerberos security handler CONFIG_AFS - The AFS filesystem Additionally, the following can be turned on to aid debugging: CONFIG_AF_RXRPC_DEBUG - Permit AF_RXRPC debugging to be enabled CONFIG_AFS_DEBUG - Permit AFS debugging to be enabled They permit the debugging messages to be turned on dynamically by manipulating the masks in the following files: /sys/module/af_rxrpc/parameters/debug /sys/module/afs/parameters/debug ===== USAGE ===== When inserting the driver modules the root cell must be specified along with a list of volume location server IP addresses: insmod rxrpc.o insmod af_rxrpc.o insmod rxkad.o insmod kafs.o rootcell=cambridge.redhat.com:172.16.18.73:172.16.18.91 The first module is a driver for the RxRPC remote operation protocol, and the second is the actual filesystem driver for the AFS filesystem. The first module is the AF_RXRPC network protocol driver. This provides the RxRPC remote operation protocol and may also be accessed from userspace. See: Documentation/networking/rxrpc.txt The second module is the kerberos RxRPC security driver, and the third module is the actual filesystem driver for the AFS filesystem. Once the module has been loaded, more modules can be added by the following procedure: Loading @@ -33,7 +84,7 @@ procedure: echo add grand.central.org 18.7.14.88:128.2.191.224 >/proc/fs/afs/cells Where the parameters to the "add" command are the name of a cell and a list of volume location servers within that cell. volume location servers within that cell, with the latter separated by colons. Filesystems can be mounted anywhere by commands similar to the following: Loading @@ -42,11 +93,6 @@ Filesystems can be mounted anywhere by commands similar to the following: mount -t afs "#root.afs." /afs mount -t afs "#root.cell." /afs/cambridge NB: When using this on Linux 2.4, the mount command has to be different, since the filesystem doesn't have access to the device name argument: mount -t afs none /afs -ovol="#root.afs." Where the initial character is either a hash or a percent symbol depending on whether you definitely want a R/W volume (hash) or whether you'd prefer a R/O volume, but are willing to use a R/W volume instead (percent). Loading @@ -60,55 +106,66 @@ named volume will be looked up in the cell specified during insmod. Additional cells can be added through /proc (see later section). =========== MOUNTPOINTS =========== AFS has a concept of mountpoints. These are specially formatted symbolic links (of the same form as the "device name" passed to mount). kAFS presents these to the user as directories that have special properties: AFS has a concept of mountpoints. In AFS terms, these are specially formatted symbolic links (of the same form as the "device name" passed to mount). kAFS presents these to the user as directories that have a follow-link capability (ie: symbolic link semantics). If anyone attempts to access them, they will automatically cause the target volume to be mounted (if possible) on that site. (*) They cannot be listed. Running a program like "ls" on them will incur an EREMOTE error (Object is remote). Automatically mounted filesystems will be automatically unmounted approximately twenty minutes after they were last used. Alternatively they can be unmounted directly with the umount() system call. (*) Other objects can't be looked up inside of them. This also incurs an EREMOTE error. Manually unmounting an AFS volume will cause any idle submounts upon it to be culled first. If all are culled, then the requested volume will also be unmounted, otherwise error EBUSY will be returned. (*) They can be queried with the readlink() system call, which will return the name of the mountpoint to which they point. The "readlink" program will also work. This can be used by the administrator to attempt to unmount the whole AFS tree mounted on /afs in one go by doing: (*) They can be mounted on (which symbolic links can't). umount /afs =============== PROC FILESYSTEM =============== The rxrpc module creates a number of files in various places in the /proc filesystem: (*) Firstly, some information files are made available in a directory called "/proc/net/rxrpc/". These list the extant transport endpoint, peer, connection and call records. (*) Secondly, some control files are made available in a directory called "/proc/sys/rxrpc/". Currently, all these files can be used for is to turn on various levels of tracing. The AFS modules creates a "/proc/fs/afs/" directory and populates it: (*) A "cells" file that lists cells currently known to the afs module. (*) A "cells" file that lists cells currently known to the afs module and their usage counts: [root@andromeda ~]# cat /proc/fs/afs/cells USE NAME 3 cambridge.redhat.com (*) A directory per cell that contains files that list volume location servers, volumes, and active servers known within that cell. [root@andromeda ~]# cat /proc/fs/afs/cambridge.redhat.com/servers USE ADDR STATE 4 172.16.18.91 0 [root@andromeda ~]# cat /proc/fs/afs/cambridge.redhat.com/vlservers ADDRESS 172.16.18.91 [root@andromeda ~]# cat /proc/fs/afs/cambridge.redhat.com/volumes USE STT VLID[0] VLID[1] VLID[2] NAME 1 Val 20000000 20000001 20000002 root.afs ================= THE CELL DATABASE ================= The filesystem maintains an internal database of all the cells it knows and the IP addresses of the volume location servers for those cells. The cell to which the computer belongs is added to the database when insmod is performed by the "rootcell=" argument. The filesystem maintains an internal database of all the cells it knows and the IP addresses of the volume location servers for those cells. The cell to which the system belongs is added to the database when insmod is performed by the "rootcell=" argument or, if compiled in, using a "kafs.rootcell=" argument on the kernel command line. Further cells can be added by commands similar to the following: Loading @@ -118,6 +175,50 @@ Further cells can be added by commands similar to the following: No other cell database operations are available at this time. ======== SECURITY ======== Secure operations are initiated by acquiring a key using the klog program. A very primitive klog program is available at: http://people.redhat.com/~dhowells/rxrpc/klog.c This should be compiled by: make klog LDLIBS="-lcrypto -lcrypt -lkrb4 -lkeyutils" And then run as: ./klog Assuming it's successful, this adds a key of type RxRPC, named for the service and cell, eg: "afs@<cellname>". This can be viewed with the keyctl program or by cat'ing /proc/keys: [root@andromeda ~]# keyctl show Session Keyring -3 --alswrv 0 0 keyring: _ses.3268 2 --alswrv 0 0 \_ keyring: _uid.0 111416553 --als--v 0 0 \_ rxrpc: afs@CAMBRIDGE.REDHAT.COM Currently the username, realm, password and proposed ticket lifetime are compiled in to the program. It is not required to acquire a key before using AFS facilities, but if one is not acquired then all operations will be governed by the anonymous user parts of the ACLs. If a key is acquired, then all AFS operations, including mounts and automounts, made by a possessor of that key will be secured with that key. If a file is opened with a particular key and then the file descriptor is passed to a process that doesn't have that key (perhaps over an AF_UNIX socket), then the operations on the file will be made with key that was used to open the file. ======== EXAMPLES ======== Loading @@ -125,8 +226,9 @@ Here's what I use to test this. Some of the names and IP addresses are local to my internal DNS. My "root.afs" partition has a mount point within it for some public volumes volumes. insmod -S /tmp/rxrpc.o insmod -S /tmp/kafs.o rootcell=cambridge.redhat.com:172.16.18.73:172.16.18.91 insmod /tmp/rxrpc.o insmod /tmp/rxkad.o insmod /tmp/kafs.o rootcell=cambridge.redhat.com:172.16.18.91 mount -t afs \%root.afs. /afs mount -t afs \%cambridge.redhat.com:root.cell. /afs/cambridge.redhat.com/ Loading @@ -141,15 +243,7 @@ mount -t afs "#grand.central.org:root.service." /afs/grand.central.org/service mount -t afs "#grand.central.org:root.software." /afs/grand.central.org/software mount -t afs "#grand.central.org:root.user." /afs/grand.central.org/user umount /afs/grand.central.org/user umount /afs/grand.central.org/software umount /afs/grand.central.org/service umount /afs/grand.central.org/project umount /afs/grand.central.org/doc umount /afs/grand.central.org/contrib umount /afs/grand.central.org/archive umount /afs/grand.central.org umount /afs/cambridge.redhat.com umount /afs rmmod kafs rmmod rxkad rmmod rxrpc
