Loading Documentation/Changes +10 −0 Original line number Original line Diff line number Diff line Loading @@ -237,6 +237,12 @@ udev udev is a userspace application for populating /dev dynamically with udev is a userspace application for populating /dev dynamically with only entries for devices actually present. udev replaces devfs. only entries for devices actually present. udev replaces devfs. FUSE ---- Needs libfuse 2.4.0 or later. Absolute minimum is 2.3.0 but mount options 'direct_io' and 'kernel_cache' won't work. Networking Networking ========== ========== Loading Loading @@ -390,6 +396,10 @@ udev ---- ---- o <http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html> o <http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html> FUSE ---- o <http://sourceforge.net/projects/fuse> Networking Networking ********** ********** Loading Documentation/SubmittingPatches +85 −1 Original line number Original line Diff line number Diff line Loading @@ -301,8 +301,84 @@ now, but you can do this to mark internal company procedures or just point out some special detail about the sign-off. point out some special detail about the sign-off. 12) The canonical patch format 12) More references for submitting patches The canonical patch subject line is: Subject: [PATCH 001/123] subsystem: summary phrase The canonical patch message body contains the following: - A "from" line specifying the patch author. - An empty line. - The body of the explanation, which will be copied to the permanent changelog to describe this patch. - The "Signed-off-by:" lines, described above, which will also go in the changelog. - A marker line containing simply "---". - Any additional comments not suitable for the changelog. - The actual patch (diff output). The Subject line format makes it very easy to sort the emails alphabetically by subject line - pretty much any email reader will support that - since because the sequence number is zero-padded, the numerical and alphabetic sort is the same. The "subsystem" in the email's Subject should identify which area or subsystem of the kernel is being patched. The "summary phrase" in the email's Subject should concisely describe the patch which that email contains. The "summary phrase" should not be a filename. Do not use the same "summary phrase" for every patch in a whole patch series. Bear in mind that the "summary phrase" of your email becomes a globally-unique identifier for that patch. It propagates all the way into the git changelog. The "summary phrase" may later be used in developer discussions which refer to the patch. People will want to google for the "summary phrase" to read discussion regarding that patch. A couple of example Subjects: Subject: [patch 2/5] ext2: improve scalability of bitmap searching Subject: [PATCHv2 001/207] x86: fix eflags tracking The "from" line must be the very first line in the message body, and has the form: From: Original Author <author@example.com> The "from" line specifies who will be credited as the author of the patch in the permanent changelog. If the "from" line is missing, then the "From:" line from the email header will be used to determine the patch author in the changelog. The explanation body will be committed to the permanent source changelog, so should make sense to a competent reader who has long since forgotten the immediate details of the discussion that might have led to this patch. The "---" marker line serves the essential purpose of marking for patch handling tools where the changelog message ends. One good use for the additional comments after the "---" marker is for a diffstat, to show what files have changed, and the number of inserted and deleted lines per file. A diffstat is especially useful on bigger patches. Other comments relevant only to the moment or the maintainer, not suitable for the permanent changelog, should also go here. See more details on the proper patch format in the following references. 13) More references for submitting patches Andrew Morton, "The perfect patch" (tpp). Andrew Morton, "The perfect patch" (tpp). <http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt> <http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt> Loading @@ -310,6 +386,14 @@ Andrew Morton, "The perfect patch" (tpp). Jeff Garzik, "Linux kernel patch submission format." Jeff Garzik, "Linux kernel patch submission format." <http://linux.yyz.us/patch-format.html> <http://linux.yyz.us/patch-format.html> Greg KH, "How to piss off a kernel subsystem maintainer" <http://www.kroah.com/log/2005/03/31/> Kernel Documentation/CodingStyle <http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle> Linus Torvald's mail on the canonical patch format: <http://lkml.org/lkml/2005/4/7/183> ----------------------------------- ----------------------------------- Loading Documentation/keys.txt +55 −19 Original line number Original line Diff line number Diff line Loading @@ -195,8 +195,8 @@ KEY ACCESS PERMISSIONS ====================== ====================== Keys have an owner user ID, a group access ID, and a permissions mask. The mask Keys have an owner user ID, a group access ID, and a permissions mask. The mask has up to eight bits each for user, group and other access. Only five of each has up to eight bits each for possessor, user, group and other access. Only set of eight bits are defined. These permissions granted are: five of each set of eight bits are defined. These permissions granted are: (*) View (*) View Loading Loading @@ -242,15 +242,15 @@ about the status of the key service: this way: this way: SERIAL FLAGS USAGE EXPY PERM UID GID TYPE DESCRIPTION: SUMMARY SERIAL FLAGS USAGE EXPY PERM UID GID TYPE DESCRIPTION: SUMMARY 00000001 I----- 39 perm 1f0000 0 0 keyring _uid_ses.0: 1/4 00000001 I----- 39 perm 1f1f0000 0 0 keyring _uid_ses.0: 1/4 00000002 I----- 2 perm 1f0000 0 0 keyring _uid.0: empty 00000002 I----- 2 perm 1f1f0000 0 0 keyring _uid.0: empty 00000007 I----- 1 perm 1f0000 0 0 keyring _pid.1: empty 00000007 I----- 1 perm 1f1f0000 0 0 keyring _pid.1: empty 0000018d I----- 1 perm 1f0000 0 0 keyring _pid.412: empty 0000018d I----- 1 perm 1f1f0000 0 0 keyring _pid.412: empty 000004d2 I--Q-- 1 perm 1f0000 32 -1 keyring _uid.32: 1/4 000004d2 I--Q-- 1 perm 1f1f0000 32 -1 keyring _uid.32: 1/4 000004d3 I--Q-- 3 perm 1f0000 32 -1 keyring _uid_ses.32: empty 000004d3 I--Q-- 3 perm 1f1f0000 32 -1 keyring _uid_ses.32: empty 00000892 I--QU- 1 perm 1f0000 0 0 user metal:copper: 0 00000892 I--QU- 1 perm 1f000000 0 0 user metal:copper: 0 00000893 I--Q-N 1 35s 1f0000 0 0 user metal:silver: 0 00000893 I--Q-N 1 35s 1f1f0000 0 0 user metal:silver: 0 00000894 I--Q-- 1 10h 1f0000 0 0 user metal:gold: 0 00000894 I--Q-- 1 10h 001f0000 0 0 user metal:gold: 0 The flags are: The flags are: Loading Loading @@ -637,6 +637,34 @@ call, and the key released upon close. How to deal with conflicting keys due to two different users opening the same file is left to the filesystem author to two different users opening the same file is left to the filesystem author to solve. solve. Note that there are two different types of pointers to keys that may be encountered: (*) struct key * This simply points to the key structure itself. Key structures will be at least four-byte aligned. (*) key_ref_t This is equivalent to a struct key *, but the least significant bit is set if the caller "possesses" the key. By "possession" it is meant that the calling processes has a searchable link to the key from one of its keyrings. There are three functions for dealing with these: key_ref_t make_key_ref(const struct key *key, unsigned long possession); struct key *key_ref_to_ptr(const key_ref_t key_ref); unsigned long is_key_possessed(const key_ref_t key_ref); The first function constructs a key reference from a key pointer and possession information (which must be 0 or 1 and not any other value). The second function retrieves the key pointer from a reference and the third retrieves the possession flag. When accessing a key's payload contents, certain precautions must be taken to When accessing a key's payload contents, certain precautions must be taken to prevent access vs modification races. See the section "Notes on accessing prevent access vs modification races. See the section "Notes on accessing payload contents" for more information. payload contents" for more information. Loading Loading @@ -665,7 +693,11 @@ payload contents" for more information. void key_put(struct key *key); void key_put(struct key *key); This can be called from interrupt context. If CONFIG_KEYS is not set then Or: void key_ref_put(key_ref_t key_ref); These can be called from interrupt context. If CONFIG_KEYS is not set then the argument will not be parsed. the argument will not be parsed. Loading @@ -689,13 +721,17 @@ payload contents" for more information. (*) If a keyring was found in the search, this can be further searched by: (*) If a keyring was found in the search, this can be further searched by: struct key *keyring_search(struct key *keyring, key_ref_t keyring_search(key_ref_t keyring_ref, const struct key_type *type, const struct key_type *type, const char *description) const char *description) This searches the keyring tree specified for a matching key. Error ENOKEY This searches the keyring tree specified for a matching key. Error ENOKEY is returned upon failure. If successful, the returned key will need to be is returned upon failure (use IS_ERR/PTR_ERR to determine). If successful, released. the returned key will need to be released. The possession attribute from the keyring reference is used to control access through the permissions mask and is propagated to the returned key reference pointer if successful. (*) To check the validity of a key, this function can be called: (*) To check the validity of a key, this function can be called: Loading Loading @@ -732,7 +768,7 @@ More complex payload contents must be allocated and a pointer to them set in key->payload.data. One of the following ways must be selected to access the key->payload.data. One of the following ways must be selected to access the data: data: (1) Unmodifyable key type. (1) Unmodifiable key type. If the key type does not have a modify method, then the key's payload can If the key type does not have a modify method, then the key's payload can be accessed without any form of locking, provided that it's known to be be accessed without any form of locking, provided that it's known to be Loading Documentation/networking/ip-sysctl.txt +7 −3 Original line number Original line Diff line number Diff line Loading @@ -355,10 +355,14 @@ ip_dynaddr - BOOLEAN Default: 0 Default: 0 icmp_echo_ignore_all - BOOLEAN icmp_echo_ignore_all - BOOLEAN If set non-zero, then the kernel will ignore all ICMP ECHO requests sent to it. Default: 0 icmp_echo_ignore_broadcasts - BOOLEAN icmp_echo_ignore_broadcasts - BOOLEAN If either is set to true, then the kernel will ignore either all If set non-zero, then the kernel will ignore all ICMP ECHO and ICMP ECHO requests sent to it or just those to broadcast/multicast TIMESTAMP requests sent to it via broadcast/multicast. addresses, respectively. Default: 1 icmp_ratelimit - INTEGER icmp_ratelimit - INTEGER Limit the maximal rates for sending ICMP packets whose type matches Limit the maximal rates for sending ICMP packets whose type matches Loading MAINTAINERS +28 −5 Original line number Original line Diff line number Diff line Loading @@ -604,6 +604,15 @@ P: H. Peter Anvin M: hpa@zytor.com M: hpa@zytor.com S: Maintained S: Maintained CPUSETS P: Paul Jackson P: Simon Derr M: pj@sgi.com M: simon.derr@bull.net L: linux-kernel@vger.kernel.org W: http://www.bullopensource.org/cpuset/ S: Supported CRAMFS FILESYSTEM CRAMFS FILESYSTEM W: http://sourceforge.net/projects/cramfs/ W: http://sourceforge.net/projects/cramfs/ S: Orphan S: Orphan Loading Loading @@ -1159,11 +1168,6 @@ L: linux1394-devel@lists.sourceforge.net W: http://www.linux1394.org/ W: http://www.linux1394.org/ S: Orphan S: Orphan IEEE 1394 SBP2 L: linux1394-devel@lists.sourceforge.net W: http://www.linux1394.org/ S: Orphan IEEE 1394 SUBSYSTEM IEEE 1394 SUBSYSTEM P: Ben Collins P: Ben Collins M: bcollins@debian.org M: bcollins@debian.org Loading Loading @@ -1198,6 +1202,15 @@ L: linux1394-devel@lists.sourceforge.net W: http://www.linux1394.org/ W: http://www.linux1394.org/ S: Maintained S: Maintained IEEE 1394 SBP2 P: Ben Collins M: bcollins@debian.org P: Stefan Richter M: stefanr@s5r6.in-berlin.de L: linux1394-devel@lists.sourceforge.net W: http://www.linux1394.org/ S: Maintained IMS TWINTURBO FRAMEBUFFER DRIVER IMS TWINTURBO FRAMEBUFFER DRIVER P: Paul Mundt P: Paul Mundt M: lethal@chaoticdreams.org M: lethal@chaoticdreams.org Loading Loading @@ -1734,8 +1747,11 @@ S: Maintained IPVS IPVS P: Wensong Zhang P: Wensong Zhang M: wensong@linux-vs.org M: wensong@linux-vs.org P: Simon Horman M: horms@verge.net.au P: Julian Anastasov P: Julian Anastasov M: ja@ssi.bg M: ja@ssi.bg L: netdev@vger.kernel.org S: Maintained S: Maintained NFS CLIENT NFS CLIENT Loading Loading @@ -1906,6 +1922,13 @@ M: joern@wh.fh-wedel.de L: linux-mtd@lists.infradead.org L: linux-mtd@lists.infradead.org S: Maintained S: Maintained PKTCDVD DRIVER P: Peter Osterlund M: petero2@telia.com L: linux-kernel@vger.kernel.org L: packet-writing@suse.com S: Maintained POSIX CLOCKS and TIMERS POSIX CLOCKS and TIMERS P: George Anzinger P: George Anzinger M: george@mvista.com M: george@mvista.com Loading Loading
Documentation/Changes +10 −0 Original line number Original line Diff line number Diff line Loading @@ -237,6 +237,12 @@ udev udev is a userspace application for populating /dev dynamically with udev is a userspace application for populating /dev dynamically with only entries for devices actually present. udev replaces devfs. only entries for devices actually present. udev replaces devfs. FUSE ---- Needs libfuse 2.4.0 or later. Absolute minimum is 2.3.0 but mount options 'direct_io' and 'kernel_cache' won't work. Networking Networking ========== ========== Loading Loading @@ -390,6 +396,10 @@ udev ---- ---- o <http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html> o <http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html> FUSE ---- o <http://sourceforge.net/projects/fuse> Networking Networking ********** ********** Loading
Documentation/SubmittingPatches +85 −1 Original line number Original line Diff line number Diff line Loading @@ -301,8 +301,84 @@ now, but you can do this to mark internal company procedures or just point out some special detail about the sign-off. point out some special detail about the sign-off. 12) The canonical patch format 12) More references for submitting patches The canonical patch subject line is: Subject: [PATCH 001/123] subsystem: summary phrase The canonical patch message body contains the following: - A "from" line specifying the patch author. - An empty line. - The body of the explanation, which will be copied to the permanent changelog to describe this patch. - The "Signed-off-by:" lines, described above, which will also go in the changelog. - A marker line containing simply "---". - Any additional comments not suitable for the changelog. - The actual patch (diff output). The Subject line format makes it very easy to sort the emails alphabetically by subject line - pretty much any email reader will support that - since because the sequence number is zero-padded, the numerical and alphabetic sort is the same. The "subsystem" in the email's Subject should identify which area or subsystem of the kernel is being patched. The "summary phrase" in the email's Subject should concisely describe the patch which that email contains. The "summary phrase" should not be a filename. Do not use the same "summary phrase" for every patch in a whole patch series. Bear in mind that the "summary phrase" of your email becomes a globally-unique identifier for that patch. It propagates all the way into the git changelog. The "summary phrase" may later be used in developer discussions which refer to the patch. People will want to google for the "summary phrase" to read discussion regarding that patch. A couple of example Subjects: Subject: [patch 2/5] ext2: improve scalability of bitmap searching Subject: [PATCHv2 001/207] x86: fix eflags tracking The "from" line must be the very first line in the message body, and has the form: From: Original Author <author@example.com> The "from" line specifies who will be credited as the author of the patch in the permanent changelog. If the "from" line is missing, then the "From:" line from the email header will be used to determine the patch author in the changelog. The explanation body will be committed to the permanent source changelog, so should make sense to a competent reader who has long since forgotten the immediate details of the discussion that might have led to this patch. The "---" marker line serves the essential purpose of marking for patch handling tools where the changelog message ends. One good use for the additional comments after the "---" marker is for a diffstat, to show what files have changed, and the number of inserted and deleted lines per file. A diffstat is especially useful on bigger patches. Other comments relevant only to the moment or the maintainer, not suitable for the permanent changelog, should also go here. See more details on the proper patch format in the following references. 13) More references for submitting patches Andrew Morton, "The perfect patch" (tpp). Andrew Morton, "The perfect patch" (tpp). <http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt> <http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt> Loading @@ -310,6 +386,14 @@ Andrew Morton, "The perfect patch" (tpp). Jeff Garzik, "Linux kernel patch submission format." Jeff Garzik, "Linux kernel patch submission format." <http://linux.yyz.us/patch-format.html> <http://linux.yyz.us/patch-format.html> Greg KH, "How to piss off a kernel subsystem maintainer" <http://www.kroah.com/log/2005/03/31/> Kernel Documentation/CodingStyle <http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle> Linus Torvald's mail on the canonical patch format: <http://lkml.org/lkml/2005/4/7/183> ----------------------------------- ----------------------------------- Loading
Documentation/keys.txt +55 −19 Original line number Original line Diff line number Diff line Loading @@ -195,8 +195,8 @@ KEY ACCESS PERMISSIONS ====================== ====================== Keys have an owner user ID, a group access ID, and a permissions mask. The mask Keys have an owner user ID, a group access ID, and a permissions mask. The mask has up to eight bits each for user, group and other access. Only five of each has up to eight bits each for possessor, user, group and other access. Only set of eight bits are defined. These permissions granted are: five of each set of eight bits are defined. These permissions granted are: (*) View (*) View Loading Loading @@ -242,15 +242,15 @@ about the status of the key service: this way: this way: SERIAL FLAGS USAGE EXPY PERM UID GID TYPE DESCRIPTION: SUMMARY SERIAL FLAGS USAGE EXPY PERM UID GID TYPE DESCRIPTION: SUMMARY 00000001 I----- 39 perm 1f0000 0 0 keyring _uid_ses.0: 1/4 00000001 I----- 39 perm 1f1f0000 0 0 keyring _uid_ses.0: 1/4 00000002 I----- 2 perm 1f0000 0 0 keyring _uid.0: empty 00000002 I----- 2 perm 1f1f0000 0 0 keyring _uid.0: empty 00000007 I----- 1 perm 1f0000 0 0 keyring _pid.1: empty 00000007 I----- 1 perm 1f1f0000 0 0 keyring _pid.1: empty 0000018d I----- 1 perm 1f0000 0 0 keyring _pid.412: empty 0000018d I----- 1 perm 1f1f0000 0 0 keyring _pid.412: empty 000004d2 I--Q-- 1 perm 1f0000 32 -1 keyring _uid.32: 1/4 000004d2 I--Q-- 1 perm 1f1f0000 32 -1 keyring _uid.32: 1/4 000004d3 I--Q-- 3 perm 1f0000 32 -1 keyring _uid_ses.32: empty 000004d3 I--Q-- 3 perm 1f1f0000 32 -1 keyring _uid_ses.32: empty 00000892 I--QU- 1 perm 1f0000 0 0 user metal:copper: 0 00000892 I--QU- 1 perm 1f000000 0 0 user metal:copper: 0 00000893 I--Q-N 1 35s 1f0000 0 0 user metal:silver: 0 00000893 I--Q-N 1 35s 1f1f0000 0 0 user metal:silver: 0 00000894 I--Q-- 1 10h 1f0000 0 0 user metal:gold: 0 00000894 I--Q-- 1 10h 001f0000 0 0 user metal:gold: 0 The flags are: The flags are: Loading Loading @@ -637,6 +637,34 @@ call, and the key released upon close. How to deal with conflicting keys due to two different users opening the same file is left to the filesystem author to two different users opening the same file is left to the filesystem author to solve. solve. Note that there are two different types of pointers to keys that may be encountered: (*) struct key * This simply points to the key structure itself. Key structures will be at least four-byte aligned. (*) key_ref_t This is equivalent to a struct key *, but the least significant bit is set if the caller "possesses" the key. By "possession" it is meant that the calling processes has a searchable link to the key from one of its keyrings. There are three functions for dealing with these: key_ref_t make_key_ref(const struct key *key, unsigned long possession); struct key *key_ref_to_ptr(const key_ref_t key_ref); unsigned long is_key_possessed(const key_ref_t key_ref); The first function constructs a key reference from a key pointer and possession information (which must be 0 or 1 and not any other value). The second function retrieves the key pointer from a reference and the third retrieves the possession flag. When accessing a key's payload contents, certain precautions must be taken to When accessing a key's payload contents, certain precautions must be taken to prevent access vs modification races. See the section "Notes on accessing prevent access vs modification races. See the section "Notes on accessing payload contents" for more information. payload contents" for more information. Loading Loading @@ -665,7 +693,11 @@ payload contents" for more information. void key_put(struct key *key); void key_put(struct key *key); This can be called from interrupt context. If CONFIG_KEYS is not set then Or: void key_ref_put(key_ref_t key_ref); These can be called from interrupt context. If CONFIG_KEYS is not set then the argument will not be parsed. the argument will not be parsed. Loading @@ -689,13 +721,17 @@ payload contents" for more information. (*) If a keyring was found in the search, this can be further searched by: (*) If a keyring was found in the search, this can be further searched by: struct key *keyring_search(struct key *keyring, key_ref_t keyring_search(key_ref_t keyring_ref, const struct key_type *type, const struct key_type *type, const char *description) const char *description) This searches the keyring tree specified for a matching key. Error ENOKEY This searches the keyring tree specified for a matching key. Error ENOKEY is returned upon failure. If successful, the returned key will need to be is returned upon failure (use IS_ERR/PTR_ERR to determine). If successful, released. the returned key will need to be released. The possession attribute from the keyring reference is used to control access through the permissions mask and is propagated to the returned key reference pointer if successful. (*) To check the validity of a key, this function can be called: (*) To check the validity of a key, this function can be called: Loading Loading @@ -732,7 +768,7 @@ More complex payload contents must be allocated and a pointer to them set in key->payload.data. One of the following ways must be selected to access the key->payload.data. One of the following ways must be selected to access the data: data: (1) Unmodifyable key type. (1) Unmodifiable key type. If the key type does not have a modify method, then the key's payload can If the key type does not have a modify method, then the key's payload can be accessed without any form of locking, provided that it's known to be be accessed without any form of locking, provided that it's known to be Loading
Documentation/networking/ip-sysctl.txt +7 −3 Original line number Original line Diff line number Diff line Loading @@ -355,10 +355,14 @@ ip_dynaddr - BOOLEAN Default: 0 Default: 0 icmp_echo_ignore_all - BOOLEAN icmp_echo_ignore_all - BOOLEAN If set non-zero, then the kernel will ignore all ICMP ECHO requests sent to it. Default: 0 icmp_echo_ignore_broadcasts - BOOLEAN icmp_echo_ignore_broadcasts - BOOLEAN If either is set to true, then the kernel will ignore either all If set non-zero, then the kernel will ignore all ICMP ECHO and ICMP ECHO requests sent to it or just those to broadcast/multicast TIMESTAMP requests sent to it via broadcast/multicast. addresses, respectively. Default: 1 icmp_ratelimit - INTEGER icmp_ratelimit - INTEGER Limit the maximal rates for sending ICMP packets whose type matches Limit the maximal rates for sending ICMP packets whose type matches Loading
MAINTAINERS +28 −5 Original line number Original line Diff line number Diff line Loading @@ -604,6 +604,15 @@ P: H. Peter Anvin M: hpa@zytor.com M: hpa@zytor.com S: Maintained S: Maintained CPUSETS P: Paul Jackson P: Simon Derr M: pj@sgi.com M: simon.derr@bull.net L: linux-kernel@vger.kernel.org W: http://www.bullopensource.org/cpuset/ S: Supported CRAMFS FILESYSTEM CRAMFS FILESYSTEM W: http://sourceforge.net/projects/cramfs/ W: http://sourceforge.net/projects/cramfs/ S: Orphan S: Orphan Loading Loading @@ -1159,11 +1168,6 @@ L: linux1394-devel@lists.sourceforge.net W: http://www.linux1394.org/ W: http://www.linux1394.org/ S: Orphan S: Orphan IEEE 1394 SBP2 L: linux1394-devel@lists.sourceforge.net W: http://www.linux1394.org/ S: Orphan IEEE 1394 SUBSYSTEM IEEE 1394 SUBSYSTEM P: Ben Collins P: Ben Collins M: bcollins@debian.org M: bcollins@debian.org Loading Loading @@ -1198,6 +1202,15 @@ L: linux1394-devel@lists.sourceforge.net W: http://www.linux1394.org/ W: http://www.linux1394.org/ S: Maintained S: Maintained IEEE 1394 SBP2 P: Ben Collins M: bcollins@debian.org P: Stefan Richter M: stefanr@s5r6.in-berlin.de L: linux1394-devel@lists.sourceforge.net W: http://www.linux1394.org/ S: Maintained IMS TWINTURBO FRAMEBUFFER DRIVER IMS TWINTURBO FRAMEBUFFER DRIVER P: Paul Mundt P: Paul Mundt M: lethal@chaoticdreams.org M: lethal@chaoticdreams.org Loading Loading @@ -1734,8 +1747,11 @@ S: Maintained IPVS IPVS P: Wensong Zhang P: Wensong Zhang M: wensong@linux-vs.org M: wensong@linux-vs.org P: Simon Horman M: horms@verge.net.au P: Julian Anastasov P: Julian Anastasov M: ja@ssi.bg M: ja@ssi.bg L: netdev@vger.kernel.org S: Maintained S: Maintained NFS CLIENT NFS CLIENT Loading Loading @@ -1906,6 +1922,13 @@ M: joern@wh.fh-wedel.de L: linux-mtd@lists.infradead.org L: linux-mtd@lists.infradead.org S: Maintained S: Maintained PKTCDVD DRIVER P: Peter Osterlund M: petero2@telia.com L: linux-kernel@vger.kernel.org L: packet-writing@suse.com S: Maintained POSIX CLOCKS and TIMERS POSIX CLOCKS and TIMERS P: George Anzinger P: George Anzinger M: george@mvista.com M: george@mvista.com Loading
