apfs/linux-apfs
0
0
Fork 0
mirror of https://github.com/linux-apfs/linux-apfs.git synced 2026-05-01 15:00:59 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into gfs2

Browse Source
This commit is contained in:
Steven Whitehouse
2006-10-02 08:45:08 -04:00
parent 825f9075d7 d834c16516
commit 59458f40e2
1836 changed files with 53173 additions and 39544 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CREDITS
+4 -2
View File
@@ -1620,7 +1620,8 @@ D: fbdev hacking
N: Jesper Juhl
E: jesper.juhl@gmail.com
D: Various fixes, cleanups and minor features.
D: Various fixes, cleanups and minor features all over the tree.
D: Wrote initial version of the hdaps driver (since passed on to others).
S: Lemnosvej 1, 3.tv
S: 2300 Copenhagen S.
S: Denmark
@@ -2477,7 +2478,8 @@ S: Derbyshire DE4 3RL
S: United Kingdom
N: Ian S. Nelson
E: ian.nelson@echostar.com
E: nelsonis@earthlink.net
P: 1024D/00D3D983 3EFD 7B86 B888 D7E2 29B6 9E97 576F 1B97 00D3 D983
D: Minor mmap and ide hacks
S: 1370 Atlantis Ave.
S: Lafayette CO, 80026
Documentation/CodingStyle
+34
View File
@@ -532,6 +532,40 @@ appears outweighs the potential value of the hint that tells gcc to do
something it would have done anyway.
Chapter 16: Function return values and names
Functions can return values of many different kinds, and one of the
most common is a value indicating whether the function succeeded or
failed. Such a value can be represented as an error-code integer
(-Exxx = failure, 0 = success) or a "succeeded" boolean (0 = failure,
non-zero = success).
Mixing up these two sorts of representations is a fertile source of
difficult-to-find bugs. If the C language included a strong distinction
between integers and booleans then the compiler would find these mistakes
for us... but it doesn't. To help prevent such bugs, always follow this
convention:
If the name of a function is an action or an imperative command,
the function should return an error-code integer. If the name
is a predicate, the function should return a "succeeded" boolean.
For example, "add work" is a command, and the add_work() function returns 0
for success or -EBUSY for failure. In the same way, "PCI device present" is
a predicate, and the pci_dev_present() function returns 1 if it succeeds in
finding a matching device or 0 if it doesn't.
All EXPORTed functions must respect this convention, and so should all
public functions. Private (static) functions need not, but it is
recommended that they do.
Functions whose return value is the actual result of a computation, rather
than an indication of whether the computation succeeded, are not subject to
this rule. Generally they indicate failure by returning some out-of-range
result. Typical examples would be functions that return pointers; they use
NULL or the ERR_PTR mechanism to report failure.
Appendix I: References
Documentation/DocBook/kernel-api.tmpl
+50 -28
View File
@@ -181,27 +181,6 @@ X!Ilib/string.c
</sect1>
</chapter>
<chapter id="proc">
<title>The proc filesystem</title>
<sect1><title>sysctl interface</title>
!Ekernel/sysctl.c
</sect1>
<sect1><title>proc filesystem interface</title>
!Ifs/proc/base.c
</sect1>
</chapter>
<chapter id="debugfs">
<title>The debugfs filesystem</title>
<sect1><title>debugfs interface</title>
!Efs/debugfs/inode.c
!Efs/debugfs/file.c
</sect1>
</chapter>
<chapter id="vfs">
<title>The Linux VFS</title>
<sect1><title>The Filesystem types</title>
@@ -234,6 +213,50 @@ X!Ilib/string.c
</sect1>
</chapter>
<chapter id="proc">
<title>The proc filesystem</title>
<sect1><title>sysctl interface</title>
!Ekernel/sysctl.c
</sect1>
<sect1><title>proc filesystem interface</title>
!Ifs/proc/base.c
</sect1>
</chapter>
<chapter id="sysfs">
<title>The Filesystem for Exporting Kernel Objects</title>
!Efs/sysfs/file.c
!Efs/sysfs/symlink.c
!Efs/sysfs/bin.c
</chapter>
<chapter id="debugfs">
<title>The debugfs filesystem</title>
<sect1><title>debugfs interface</title>
!Efs/debugfs/inode.c
!Efs/debugfs/file.c
</sect1>
</chapter>
<chapter id="relayfs">
<title>relay interface support</title>
<para>
Relay interface support
is designed to provide an efficient mechanism for tools and
facilities to relay large amounts of data from kernel space to
user space.
</para>
<sect1><title>relay interface</title>
!Ekernel/relay.c
!Ikernel/relay.c
</sect1>
</chapter>
<chapter id="netcore">
<title>Linux Networking</title>
<sect1><title>Networking Base Types</title>
@@ -349,13 +372,6 @@ X!Earch/i386/kernel/mca.c
</sect1>
</chapter>
<chapter id="sysfs">
<title>The Filesystem for Exporting Kernel Objects</title>
!Efs/sysfs/file.c
!Efs/sysfs/symlink.c
!Efs/sysfs/bin.c
</chapter>
<chapter id="security">
<title>Security Framework</title>
!Esecurity/security.c
@@ -386,6 +402,7 @@ X!Iinclude/linux/device.h
-->
!Edrivers/base/driver.c
!Edrivers/base/core.c
!Edrivers/base/class.c
!Edrivers/base/firmware_class.c
!Edrivers/base/transport_class.c
!Edrivers/base/dmapool.c
@@ -437,6 +454,11 @@ X!Edrivers/pnp/system.c
!Eblock/ll_rw_blk.c
</chapter>
<chapter id="chrdev">
<title>Char devices</title>
!Efs/char_dev.c
</chapter>
<chapter id="miscdev">
<title>Miscellaneous Devices</title>
!Edrivers/char/misc.c
Documentation/HOWTO
+20
View File
@@ -375,6 +375,26 @@ of information is needed by the kernel developers to help track down the
problem.
Managing bug reports
--------------------
One of the best ways to put into practice your hacking skills is by fixing
bugs reported by other people. Not only you will help to make the kernel
more stable, you'll learn to fix real world problems and you will improve
your skills, and other developers will be aware of your presence. Fixing
bugs is one of the best ways to earn merit amongst the developers, because
not many people like wasting time fixing other people's bugs.
To work in the already reported bug reports, go to http://bugzilla.kernel.org.
If you want to be advised of the future bug reports, you can subscribe to the
bugme-new mailing list (only new bug reports are mailed here) or to the
bugme-janitor mailing list (every change in the bugzilla is mailed here)
http://lists.osdl.org/mailman/listinfo/bugme-new
http://lists.osdl.org/mailman/listinfo/bugme-janitors
Mailing lists
-------------
Documentation/IPMI.txt
+6 -3
View File
@@ -326,9 +326,12 @@ for events, they will all receive all events that come in.
For receiving commands, you have to individually register commands you
want to receive. Call ipmi_register_for_cmd() and supply the netfn
and command name for each command you want to receive. Only one user
may be registered for each netfn/cmd, but different users may register
for different commands.
and command name for each command you want to receive. You also
specify a bitmask of the channels you want to receive the command from
(or use IPMI_CHAN_ALL for all channels if you don't care). Only one
user may be registered for each netfn/cmd/channel, but different users
may register for different commands, or the same command if the
channel bitmasks do not overlap.
From userland, equivalent IOCTLs are provided to do these functions.
Documentation/SubmitChecklist
+5
View File
@@ -61,3 +61,8 @@ kernel patches.
Documentation/kernel-parameters.txt.
18: All new module parameters are documented with MODULE_PARM_DESC()
19: All new userspace interfaces are documented in Documentation/ABI/.
See Documentation/ABI/README for more information.
20: Check that it all passes `make headers_check'.
Documentation/SubmittingDrivers
+7 -14
View File
@@ -59,11 +59,11 @@ Copyright: The copyright owner must agree to use of GPL.
are the same person/entity. If not, the name of
the person/entity authorizing use of GPL should be
listed in case it's necessary to verify the will of
the copright owner.
the copyright owner.
Interfaces: If your driver uses existing interfaces and behaves like
other drivers in the same class it will be much more likely
to be accepted than if it invents gratuitous new ones.
to be accepted than if it invents gratuitous new ones.
If you need to implement a common API over Linux and NT
drivers do it in userspace.
@@ -88,7 +88,7 @@ Clarity: It helps if anyone can see how to fix the driver. It helps
it will go in the bitbucket.
Control: In general if there is active maintainance of a driver by
the author then patches will be redirected to them unless
the author then patches will be redirected to them unless
they are totally obvious and without need of checking.
If you want to be the contact and update point for the
driver it is a good idea to state this in the comments,
@@ -100,7 +100,7 @@ What Criteria Do Not Determine Acceptance
Vendor: Being the hardware vendor and maintaining the driver is
often a good thing. If there is a stable working driver from
other people already in the tree don't expect 'we are the
vendor' to get your driver chosen. Ideally work with the
vendor' to get your driver chosen. Ideally work with the
existing driver author to build a single perfect driver.
Author: It doesn't matter if a large Linux company wrote the driver,
@@ -116,17 +116,13 @@ Linux kernel master tree:
ftp.??.kernel.org:/pub/linux/kernel/...
?? == your country code, such as "us", "uk", "fr", etc.
Linux kernel mailing list:
Linux kernel mailing list:
linux-kernel@vger.kernel.org
[mail majordomo@vger.kernel.org to subscribe]
Linux Device Drivers, Third Edition (covers 2.6.10):
http://lwn.net/Kernel/LDD3/ (free version)
Kernel traffic:
Weekly summary of kernel list activity (much easier to read)
http://www.kerneltraffic.org/kernel-traffic/
LWN.net:
Weekly summary of kernel development activity - http://lwn.net/
2.6 API changes:
@@ -145,11 +141,8 @@ KernelNewbies:
Linux USB project:
http://www.linux-usb.org/
How to NOT write kernel driver by arjanv@redhat.com
http://people.redhat.com/arjanv/olspaper.pdf
How to NOT write kernel driver by Arjan van de Ven:
http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf
Kernel Janitor:
http://janitor.kernelnewbies.org/
--
Last updated on 17 Nov 2005.
Documentation/SubmittingPatches
+26 -13
View File
@@ -173,15 +173,15 @@ For small patches you may want to CC the Trivial Patch Monkey
trivial@kernel.org managed by Adrian Bunk; which collects "trivial"
patches. Trivial patches must qualify for one of the following rules:
Spelling fixes in documentation
Spelling fixes which could break grep(1).
Spelling fixes which could break grep(1)
Warning fixes (cluttering with useless warnings is bad)
Compilation fixes (only if they are actually correct)
Runtime fixes (only if they actually fix things)
Removing use of deprecated functions/macros (eg. check_region).
Removing use of deprecated functions/macros (eg. check_region)
Contact detail and documentation fixes
Non-portable code replaced by portable code (even in arch-specific,
since people copy, as long as it's trivial)
Any fix by the author/maintainer of the file. (ie. patch monkey
Any fix by the author/maintainer of the file (ie. patch monkey
in re-transmission mode)
URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/>
@@ -209,6 +209,19 @@ Exception: If your mailer is mangling patches then someone may ask
you to re-send them using MIME.
WARNING: Some mailers like Mozilla send your messages with
---- message header ----
Content-Type: text/plain; charset=us-ascii; format=flowed
---- message header ----
The problem is that "format=flowed" makes some of the mailers
on receiving side to replace TABs with spaces and do similar
changes. Thus the patches from you can look corrupted.
To fix this just make your mozilla defaults/pref/mailnews.js file to look like:
pref("mailnews.send_plaintext_flowed", false); // RFC 2646=======
pref("mailnews.display.disable_format_flowed_support", true);
7) E-mail size.
@@ -245,13 +258,13 @@ updated change.
It is quite common for Linus to "drop" your patch without comment.
That's the nature of the system. If he drops your patch, it could be
due to
* Your patch did not apply cleanly to the latest kernel version
* Your patch did not apply cleanly to the latest kernel version.
* Your patch was not sufficiently discussed on linux-kernel.
* A style issue (see section 2),
* An e-mail formatting issue (re-read this section)
* A technical problem with your change
* He gets tons of e-mail, and yours got lost in the shuffle
* You are being annoying (See Figure 1)
* A style issue (see section 2).
* An e-mail formatting issue (re-read this section).
* A technical problem with your change.
* He gets tons of e-mail, and yours got lost in the shuffle.
* You are being annoying.
When in doubt, solicit comments on linux-kernel mailing list.
@@ -476,10 +489,10 @@ SECTION 3 - REFERENCES
Andrew Morton, "The perfect patch" (tpp).
<http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt>
Jeff Garzik, "Linux kernel patch submission format."
Jeff Garzik, "Linux kernel patch submission format".
<http://linux.yyz.us/patch-format.html>
Greg Kroah-Hartman "How to piss off a kernel subsystem maintainer".
Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
<http://www.kroah.com/log/2005/03/31/>
<http://www.kroah.com/log/2005/07/08/>
<http://www.kroah.com/log/2005/10/19/>
@@ -488,9 +501,9 @@ Greg Kroah-Hartman "How to piss off a kernel subsystem maintainer".
NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
<http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
Kernel Documentation/CodingStyle
Kernel Documentation/CodingStyle:
<http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle>
Linus Torvald's mail on the canonical patch format:
Linus Torvalds's mail on the canonical patch format:
<http://lkml.org/lkml/2005/4/7/183>
--
Documentation/accounting/getdelays.c
+4 -3
View File
@@ -285,7 +285,7 @@ int main(int argc, char *argv[])
if (maskset) {
rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET,
TASKSTATS_CMD_ATTR_REGISTER_CPUMASK,
&cpumask, sizeof(cpumask));
&cpumask, strlen(cpumask) + 1);
PRINTF("Sent register cpumask, retval %d\n", rc);
if (rc < 0) {
printf("error sending register cpumask\n");
@@ -315,7 +315,8 @@ int main(int argc, char *argv[])
}
if (msg.n.nlmsg_type == NLMSG_ERROR ||
!NLMSG_OK((&msg.n), rep_len)) {
printf("fatal reply error, errno %d\n", errno);
struct nlmsgerr *err = NLMSG_DATA(&msg);
printf("fatal reply error, errno %d\n", err->error);
goto done;
}
@@ -383,7 +384,7 @@ done:
if (maskset) {
rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET,
TASKSTATS_CMD_ATTR_DEREGISTER_CPUMASK,
&cpumask, sizeof(cpumask));
&cpumask, strlen(cpumask) + 1);
printf("Sent deregister mask, retval %d\n", rc);
if (rc < 0)
err(rc, "error sending deregister cpumask\n");
Documentation/accounting/taskstats-struct.txt
+161
View File
@@ -0,0 +1,161 @@
The struct taskstats
--------------------
This document contains an explanation of the struct taskstats fields.
There are three different groups of fields in the struct taskstats:
1) Common and basic accounting fields
If CONFIG_TASKSTATS is set, the taskstats inteface is enabled and
the common fields and basic accounting fields are collected for
delivery at do_exit() of a task.
2) Delay accounting fields
These fields are placed between
/* Delay accounting fields start */
and
/* Delay accounting fields end */
Their values are collected if CONFIG_TASK_DELAY_ACCT is set.
3) Extended accounting fields
These fields are placed between
/* Extended accounting fields start */
and
/* Extended accounting fields end */
Their values are collected if CONFIG_TASK_XACCT is set.
Future extension should add fields to the end of the taskstats struct, and
should not change the relative position of each field within the struct.
struct taskstats {
1) Common and basic accounting fields:
/* The version number of this struct. This field is always set to
* TAKSTATS_VERSION, which is defined in <linux/taskstats.h>.
* Each time the struct is changed, the value should be incremented.
*/
__u16 version;
/* The exit code of a task. */
__u32 ac_exitcode; /* Exit status */
/* The accounting flags of a task as defined in <linux/acct.h>
* Defined values are AFORK, ASU, ACOMPAT, ACORE, and AXSIG.
*/
__u8 ac_flag; /* Record flags */
/* The value of task_nice() of a task. */
__u8 ac_nice; /* task_nice */
/* The name of the command that started this task. */
char ac_comm[TS_COMM_LEN]; /* Command name */
/* The scheduling discipline as set in task->policy field. */
__u8 ac_sched; /* Scheduling discipline */
__u8 ac_pad[3];
__u32 ac_uid; /* User ID */
__u32 ac_gid; /* Group ID */
__u32 ac_pid; /* Process ID */
__u32 ac_ppid; /* Parent process ID */
/* The time when a task begins, in [secs] since 1970. */
__u32 ac_btime; /* Begin time [sec since 1970] */
/* The elapsed time of a task, in [usec]. */
__u64 ac_etime; /* Elapsed time [usec] */
/* The user CPU time of a task, in [usec]. */
__u64 ac_utime; /* User CPU time [usec] */
/* The system CPU time of a task, in [usec]. */
__u64 ac_stime; /* System CPU time [usec] */
/* The minor page fault count of a task, as set in task->min_flt. */
__u64 ac_minflt; /* Minor Page Fault Count */
/* The major page fault count of a task, as set in task->maj_flt. */
__u64 ac_majflt; /* Major Page Fault Count */
2) Delay accounting fields:
/* Delay accounting fields start
*
* All values, until the comment "Delay accounting fields end" are
* available only if delay accounting is enabled, even though the last
* few fields are not delays
*
* xxx_count is the number of delay values recorded
* xxx_delay_total is the corresponding cumulative delay in nanoseconds
*
* xxx_delay_total wraps around to zero on overflow
* xxx_count incremented regardless of overflow
*/
/* Delay waiting for cpu, while runnable
* count, delay_total NOT updated atomically
*/
__u64 cpu_count;
__u64 cpu_delay_total;
/* Following four fields atomically updated using task->delays->lock */
/* Delay waiting for synchronous block I/O to complete
* does not account for delays in I/O submission
*/
__u64 blkio_count;
__u64 blkio_delay_total;
/* Delay waiting for page fault I/O (swap in only) */
__u64 swapin_count;
__u64 swapin_delay_total;
/* cpu "wall-clock" running time
* On some architectures, value will adjust for cpu time stolen
* from the kernel in involuntary waits due to virtualization.
* Value is cumulative, in nanoseconds, without a corresponding count
* and wraps around to zero silently on overflow
*/
__u64 cpu_run_real_total;
/* cpu "virtual" running time
* Uses time intervals seen by the kernel i.e. no adjustment
* for kernel's involuntary waits due to virtualization.
* Value is cumulative, in nanoseconds, without a corresponding count
* and wraps around to zero silently on overflow
*/
__u64 cpu_run_virtual_total;
/* Delay accounting fields end */
/* version 1 ends here */
3) Extended accounting fields
/* Extended accounting fields start */
/* Accumulated RSS usage in duration of a task, in MBytes-usecs.
* The current rss usage is added to this counter every time
* a tick is charged to a task's system time. So, at the end we
* will have memory usage multiplied by system time. Thus an
* average usage per system time unit can be calculated.
*/
__u64 coremem; /* accumulated RSS usage in MB-usec */
/* Accumulated virtual memory usage in duration of a task.
* Same as acct_rss_mem1 above except that we keep track of VM usage.
*/
__u64 virtmem; /* accumulated VM usage in MB-usec */
/* High watermark of RSS usage in duration of a task, in KBytes. */
__u64 hiwater_rss; /* High-watermark of RSS usage */
/* High watermark of VM usage in duration of a task, in KBytes. */
__u64 hiwater_vm; /* High-water virtual memory usage */
/* The following four fields are I/O statistics of a task. */
__u64 read_char; /* bytes read */
__u64 write_char; /* bytes written */
__u64 read_syscalls; /* read syscalls */
__u64 write_syscalls; /* write syscalls */
/* Extended accounting fields end */
}
Documentation/cpusets.txt
+5 -5
View File
@@ -217,11 +217,11 @@ exclusive cpuset. Also, the use of a Linux virtual file system (vfs)
to represent the cpuset hierarchy provides for a familiar permission
and name space for cpusets, with a minimum of additional kernel code.
The cpus file in the root (top_cpuset) cpuset is read-only.
It automatically tracks the value of cpu_online_map, using a CPU
hotplug notifier. If and when memory nodes can be hotplugged,
we expect to make the mems file in the root cpuset read-only
as well, and have it track the value of node_online_map.
The cpus and mems files in the root (top_cpuset) cpuset are
read-only. The cpus file automatically tracks the value of
cpu_online_map using a CPU hotplug notifier, and the mems file
automatically tracks the value of node_online_map using the
cpuset_track_online_nodes() hook.
1.4 What are exclusive cpusets ?
Documentation/fb/intelfb.txt
+7 -4
View File
@@ -1,16 +1,19 @@
Intel 830M/845G/852GM/855GM/865G/915G Framebuffer driver
Intel 830M/845G/852GM/855GM/865G/915G/945G Framebuffer driver
================================================================
A. Introduction
This is a framebuffer driver for various Intel 810/815 compatible
This is a framebuffer driver for various Intel 8xx/9xx compatible
graphics devices. These would include:
Intel 830M
Intel 810E845G
Intel 845G
Intel 852GM
Intel 855GM
Intel 865G
Intel 915G
Intel 915GM
Intel 945G
Intel 945GM
B. List of available options
@@ -78,7 +81,7 @@ C. Kernel booting
Separate each option/option-pair by commas (,) and the option from its value
with an equals sign (=) as in the following:
video=i810fb:option1,option2=value2
video=intelfb:option1,option2=value2
Sample Usage
------------
Documentation/feature-removal-schedule.txt
+1 -10
View File
@@ -46,17 +46,8 @@ Who: Jody McIntyre <scjody@modernduck.com>
---------------------------
What: sbp2: module parameter "force_inquiry_hack"
When: July 2006
Why: Superceded by parameter "workarounds". Both parameters are meant to be
used ad-hoc and for single devices only, i.e. not in modprobe.conf,
therefore the impact of this feature replacement should be low.
Who: Stefan Richter <stefanr@s5r6.in-berlin.de>
---------------------------
What: Video4Linux API 1 ioctls and video_decoder.h from Video devices.
When: July 2006
When: December 2006
Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6
series. The old API have lots of drawbacks and don't provide enough
means to work with all video and audio standards. The newer API is
Documentation/filesystems/Locking
+2 -3
View File
@@ -356,10 +356,9 @@ The last two are called only from check_disk_change().
prototypes:
loff_t (*llseek) (struct file *, loff_t, int);
ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
ssize_t (*aio_read) (struct kiocb *, char __user *, size_t, loff_t);
ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
ssize_t (*aio_write) (struct kiocb *, const char __user *, size_t,
loff_t);
ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
int (*readdir) (struct file *, void *, filldir_t);
unsigned int (*poll) (struct file *, struct poll_table_struct *);
int (*ioctl) (struct inode *, struct file *, unsigned int,
Documentation/filesystems/proc.txt
+18
View File
@@ -39,6 +39,8 @@ Table of Contents
2.9 Appletalk
2.10 IPX
2.11 /proc/sys/fs/mqueue - POSIX message queues filesystem
2.12 /proc/<pid>/oom_adj - Adjust the oom-killer score
2.13 /proc/<pid>/oom_score - Display current oom-killer score
------------------------------------------------------------------------------
Preface
@@ -1962,6 +1964,22 @@ a queue must be less or equal then msg_max.
maximum message size value (it is every message queue's attribute set during
its creation).
2.12 /proc/<pid>/oom_adj - Adjust the oom-killer score
------------------------------------------------------
This file can be used to adjust the score used to select which processes
should be killed in an out-of-memory situation. Giving it a high score will
increase the likelihood of this process being killed by the oom-killer. Valid
values are in the range -16 to +15, plus the special value -17, which disables
oom-killing altogether for this process.
2.13 /proc/<pid>/oom_score - Display current oom-killer score
-------------------------------------------------------------
------------------------------------------------------------------------------
This file can be used to check the current score used by the oom-killer is for
any given <pid>. Use it together with /proc/<pid>/oom_adj to tune which
process should be killed in an out-of-memory situation.
------------------------------------------------------------------------------
Summary
Documentation/filesystems/vfs.txt
+2 -2
View File
@@ -699,9 +699,9 @@ This describes how the VFS can manipulate an open file. As of kernel
struct file_operations {
loff_t (*llseek) (struct file *, loff_t, int);
ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
ssize_t (*aio_read) (struct kiocb *, char __user *, size_t, loff_t);
ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
ssize_t (*aio_write) (struct kiocb *, const char __user *, size_t, loff_t);
ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
int (*readdir) (struct file *, void *, filldir_t);
unsigned int (*poll) (struct file *, struct poll_table_struct *);
int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long);
Documentation/hwmon/it87
+47 -14
View File
@@ -13,12 +13,25 @@ Supported chips:
from Super I/O config space (8 I/O ports)
Datasheet: Publicly available at the ITE website
http://www.ite.com.tw/
* IT8716F
Prefix: 'it8716'
Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Publicly available at the ITE website
http://www.ite.com.tw/product_info/file/pc/IT8716F_V0.3.ZIP
* IT8718F
Prefix: 'it8718'
Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Publicly available at the ITE website
http://www.ite.com.tw/product_info/file/pc/IT8718F_V0.2.zip
http://www.ite.com.tw/product_info/file/pc/IT8718F_V0%203_(for%20C%20version).zip
* SiS950 [clone of IT8705F]
Prefix: 'it87'
Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: No longer be available
Author: Christophe Gauthron <chrisg@0-in.com>
Authors:
Christophe Gauthron <chrisg@0-in.com>
Jean Delvare <khali@linux-fr.org>
Module Parameters
@@ -43,26 +56,46 @@ Module Parameters
Description
-----------
This driver implements support for the IT8705F, IT8712F and SiS950 chips.
This driver also supports IT8712F, which adds SMBus access, and a VID
input, used to report the Vcore voltage of the Pentium processor.
The IT8712F additionally features VID inputs.
This driver implements support for the IT8705F, IT8712F, IT8716F,
IT8718F and SiS950 chips.
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
joysticks and other miscellaneous stuff. For hardware monitoring, they
include an 'environment controller' with 3 temperature sensors, 3 fan
rotation speed sensors, 8 voltage sensors, and associated alarms.
The IT8712F and IT8716F additionally feature VID inputs, used to report
the Vcore voltage of the processor. The early IT8712F have 5 VID pins,
the IT8716F and late IT8712F have 6. They are shared with other functions
though, so the functionality may not be available on a given system.
The driver dumbly assume it is there.
The IT8718F also features VID inputs (up to 8 pins) but the value is
stored in the Super-I/O configuration space. Due to technical limitations,
this value can currently only be read once at initialization time, so
the driver won't notice and report changes in the VID value. The two
upper VID bits share their pins with voltage inputs (in5 and in6) so you
can't have both on a given board.
The IT8716F, IT8718F and later IT8712F revisions have support for
2 additional fans. They are not yet supported by the driver.
The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional
16-bit tachometer counters for fans 1 to 3. This is better (no more fan
clock divider mess) but not compatible with the older chips and
revisions. For now, the driver only uses the 16-bit mode on the
IT8716F and IT8718F.
Temperatures are measured in degrees Celsius. An alarm is triggered once
when the Overtemperature Shutdown limit is crossed.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give the
readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
triggered if the rotation speed has dropped below a programmable limit. When
16-bit tachometer counters aren't used, fan readings can be divided by
a programmable divider (1, 2, 4 or 8) to give the readings more range or
accuracy. With a divider of 2, the lowest representable value is around
2600 RPM. Not all RPM values can accurately be represented, so some rounding
is done.
Voltage sensors (also known as IN sensors) report their values in volts. An
alarm is triggered if the voltage has crossed a programmable minimum or
@@ -71,9 +104,9 @@ zero'; this is important for negative voltage measurements. All voltage
inputs can measure voltages between 0 and 4.08 volts, with a resolution of
0.016 volt. The battery voltage in8 does not have limit registers.
The VID lines (IT8712F only) encode the core voltage value: the voltage
level your processor should work with. This is hardcoded by the mainboard
and/or processor itself. It is a value in volts.
The VID lines (IT8712F/IT8716F/IT8718F) encode the core voltage value:
the voltage level your processor should work with. This is hardcoded by
the mainboard and/or processor itself. It is a value in volts.
If an alarm triggers, it will remain triggered until the hardware register
is read at least once. This means that the cause for the alarm may already
Documentation/hwmon/k8temp
+52
View File
@@ -0,0 +1,52 @@
Kernel driver k8temp
====================
Supported chips:
* AMD K8 CPU
Prefix: 'k8temp'
Addresses scanned: PCI space
Datasheet: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf
Author: Rudolf Marek
Contact: Rudolf Marek <r.marek@sh.cvut.cz>
Description
-----------
This driver permits reading temperature sensor(s) embedded inside AMD K8 CPUs.
Official documentation says that it works from revision F of K8 core, but
in fact it seems to be implemented for all revisions of K8 except the first
two revisions (SH-B0 and SH-B3).
There can be up to four temperature sensors inside single CPU. The driver
will auto-detect the sensors and will display only temperatures from
implemented sensors.
Mapping of /sys files is as follows:
temp1_input - temperature of Core 0 and "place" 0
temp2_input - temperature of Core 0 and "place" 1
temp3_input - temperature of Core 1 and "place" 0
temp4_input - temperature of Core 1 and "place" 1
Temperatures are measured in degrees Celsius and measurement resolution is
1 degree C. It is expected that future CPU will have better resolution. The
temperature is updated once a second. Valid temperatures are from -49 to
206 degrees C.
Temperature known as TCaseMax was specified for processors up to revision E.
This temperature is defined as temperature between heat-spreader and CPU
case, so the internal CPU temperature supplied by this driver can be higher.
There is no easy way how to measure the temperature which will correlate
with TCaseMax temperature.
For newer revisions of CPU (rev F, socket AM2) there is a mathematically
computed temperature called TControl, which must be lower than TControlMax.
The relationship is following:
temp1_input - TjOffset*2 < TControlMax,
TjOffset is not yet exported by the driver, TControlMax is usually
70 degrees C. The rule of the thumb -> CPU temperature should not cross
60 degrees C too much.
Documentation/hwmon/vt1211
+206
View File
@@ -0,0 +1,206 @@
Kernel driver vt1211
====================
Supported chips:
* VIA VT1211
Prefix: 'vt1211'
Addresses scanned: none, address read from Super-I/O config space
Datasheet: Provided by VIA upon request and under NDA
Authors: Juerg Haefliger <juergh@gmail.com>
This driver is based on the driver for kernel 2.4 by Mark D. Studebaker and
its port to kernel 2.6 by Lars Ekman.
Thanks to Joseph Chan and Fiona Gatt from VIA for providing documentation and
technical support.
Module Parameters
-----------------
* uch_config: int Override the BIOS default universal channel (UCH)
configuration for channels 1-5.
Legal values are in the range of 0-31. Bit 0 maps to
UCH1, bit 1 maps to UCH2 and so on. Setting a bit to 1
enables the thermal input of that particular UCH and
setting a bit to 0 enables the voltage input.
* int_mode: int Override the BIOS default temperature interrupt mode.
The only possible value is 0 which forces interrupt
mode 0. In this mode, any pending interrupt is cleared
when the status register is read but is regenerated as
long as the temperature stays above the hysteresis
limit.
Be aware that overriding BIOS defaults might cause some unwanted side effects!
Description
-----------
The VIA VT1211 Super-I/O chip includes complete hardware monitoring
capabilities. It monitors 2 dedicated temperature sensor inputs (temp1 and
temp2), 1 dedicated voltage (in5) and 2 fans. Additionally, the chip
implements 5 universal input channels (UCH1-5) that can be individually
programmed to either monitor a voltage or a temperature.
This chip also provides manual and automatic control of fan speeds (according
to the datasheet). The driver only supports automatic control since the manual
mode doesn't seem to work as advertised in the datasheet. In fact I couldn't
get manual mode to work at all! Be aware that automatic mode hasn't been
tested very well (due to the fact that my EPIA M10000 doesn't have the fans
connected to the PWM outputs of the VT1211 :-().
The following table shows the relationship between the vt1211 inputs and the
sysfs nodes.
Sensor Voltage Mode Temp Mode Default Use (from the datasheet)
------ ------------ --------- --------------------------------
Reading 1 temp1 Intel thermal diode
Reading 3 temp2 Internal thermal diode
UCH1/Reading2 in0 temp3 NTC type thermistor
UCH2 in1 temp4 +2.5V
UCH3 in2 temp5 VccP (processor core)
UCH4 in3 temp6 +5V
UCH5 in4 temp7 +12V
+3.3V in5 Internal VCC (+3.3V)
Voltage Monitoring
------------------
Voltages are sampled by an 8-bit ADC with a LSB of ~10mV. The supported input
range is thus from 0 to 2.60V. Voltage values outside of this range need
external scaling resistors. This external scaling needs to be compensated for
via compute lines in sensors.conf, like:
compute inx @*(1+R1/R2), @/(1+R1/R2)
The board level scaling resistors according to VIA's recommendation are as
follows. And this is of course totally dependent on the actual board
implementation :-) You will have to find documentation for your own
motherboard and edit sensors.conf accordingly.
Expected
Voltage R1 R2 Divider Raw Value
-----------------------------------------------
+2.5V 2K 10K 1.2 2083 mV
VccP --- --- 1.0 1400 mV (1)
+5V 14K 10K 2.4 2083 mV
+12V 47K 10K 5.7 2105 mV
+3.3V (int) 2K 3.4K 1.588 3300 mV (2)
+3.3V (ext) 6.8K 10K 1.68 1964 mV
(1) Depending on the CPU (1.4V is for a VIA C3 Nehemiah).
(2) R1 and R2 for 3.3V (int) are internal to the VT1211 chip and the driver
performs the scaling and returns the properly scaled voltage value.
Each measured voltage has an associated low and high limit which triggers an
alarm when crossed.
Temperature Monitoring
----------------------
Temperatures are reported in millidegree Celsius. Each measured temperature
has a high limit which triggers an alarm if crossed. There is an associated
hysteresis value with each temperature below which the temperature has to drop
before the alarm is cleared (this is only true for interrupt mode 0). The
interrupt mode can be forced to 0 in case the BIOS doesn't do it
automatically. See the 'Module Parameters' section for details.
All temperature channels except temp2 are external. Temp2 is the VT1211
internal thermal diode and the driver does all the scaling for temp2 and
returns the temperature in millidegree Celsius. For the external channels
temp1 and temp3-temp7, scaling depends on the board implementation and needs
to be performed in userspace via sensors.conf.
Temp1 is an Intel-type thermal diode which requires the following formula to
convert between sysfs readings and real temperatures:
compute temp1 (@-Offset)/Gain, (@*Gain)+Offset
According to the VIA VT1211 BIOS porting guide, the following gain and offset
values should be used:
Diode Type Offset Gain
---------- ------ ----
Intel CPU 88.638 0.9528
65.000 0.9686 *)
VIA C3 Ezra 83.869 0.9528
VIA C3 Ezra-T 73.869 0.9528
*) This is the formula from the lm_sensors 2.10.0 sensors.conf file. I don't
know where it comes from or how it was derived, it's just listed here for
completeness.
Temp3-temp7 support NTC thermistors. For these channels, the driver returns
the voltages as seen at the individual pins of UCH1-UCH5. The voltage at the
pin (Vpin) is formed by a voltage divider made of the thermistor (Rth) and a
scaling resistor (Rs):
Vpin = 2200 * Rth / (Rs + Rth) (2200 is the ADC max limit of 2200 mV)
The equation for the thermistor is as follows (google it if you want to know
more about it):
Rth = Ro * exp(B * (1 / T - 1 / To)) (To is 298.15K (25C) and Ro is the
nominal resistance at 25C)
Mingling the above two equations and assuming Rs = Ro and B = 3435 yields the
following formula for sensors.conf:
compute tempx 1 / (1 / 298.15 - (` (2200 / @ - 1)) / 3435) - 273.15,
2200 / (1 + (^ (3435 / 298.15 - 3435 / (273.15 + @))))
Fan Speed Control
-----------------
The VT1211 provides 2 programmable PWM outputs to control the speeds of 2
fans. Writing a 2 to any of the two pwm[1-2]_enable sysfs nodes will put the
PWM controller in automatic mode. There is only a single controller that
controls both PWM outputs but each PWM output can be individually enabled and
disabled.
Each PWM has 4 associated distinct output duty-cycles: full, high, low and
off. Full and off are internally hard-wired to 255 (100%) and 0 (0%),
respectively. High and low can be programmed via
pwm[1-2]_auto_point[2-3]_pwm. Each PWM output can be associated with a
different thermal input but - and here's the weird part - only one set of
thermal thresholds exist that controls both PWMs output duty-cycles. The
thermal thresholds are accessible via pwm[1-2]_auto_point[1-4]_temp. Note
that even though there are 2 sets of 4 auto points each, they map to the same
registers in the VT1211 and programming one set is sufficient (actually only
the first set pwm1_auto_point[1-4]_temp is writable, the second set is
read-only).
PWM Auto Point PWM Output Duty-Cycle
------------------------------------------------
pwm[1-2]_auto_point4_pwm full speed duty-cycle (hard-wired to 255)
pwm[1-2]_auto_point3_pwm high speed duty-cycle
pwm[1-2]_auto_point2_pwm low speed duty-cycle
pwm[1-2]_auto_point1_pwm off duty-cycle (hard-wired to 0)
Temp Auto Point Thermal Threshold
---------------------------------------------
pwm[1-2]_auto_point4_temp full speed temp
pwm[1-2]_auto_point3_temp high speed temp
pwm[1-2]_auto_point2_temp low speed temp
pwm[1-2]_auto_point1_temp off temp
Long story short, the controller implements the following algorithm to set the
PWM output duty-cycle based on the input temperature:
Thermal Threshold Output Duty-Cycle
(Rising Temp) (Falling Temp)
----------------------------------------------------------
full speed duty-cycle full speed duty-cycle
full speed temp
high speed duty-cycle full speed duty-cycle
high speed temp
low speed duty-cycle high speed duty-cycle
low speed temp
off duty-cycle low speed duty-cycle
off temp
Documentation/hwmon/w83627ehf
+85
View File
@@ -0,0 +1,85 @@
Kernel driver w83627ehf
=======================
Supported chips:
* Winbond W83627EHF/EHG (ISA access ONLY)
Prefix: 'w83627ehf'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83627EHF_%20W83627EHGb.pdf
Authors:
Jean Delvare <khali@linux-fr.org>
Yuan Mu (Winbond)
Rudolf Marek <r.marek@sh.cvut.cz>
Description
-----------
This driver implements support for the Winbond W83627EHF and W83627EHG
super I/O chips. We will refer to them collectively as Winbond chips.
The chips implement three temperature sensors, five fan rotation
speed sensors, ten analog voltage sensors, alarms with beep warnings (control
unimplemented), and some automatic fan regulation strategies (plus manual
fan control mode).
Temperatures are measured in degrees Celsius and measurement resolution is 1
degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when
the temperature gets higher than high limit; it stays on until the temperature
falls below the Hysteresis value.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4, 8, 16, 32, 64 or
128) to give the readings more range or accuracy. The driver sets the most
suitable fan divisor itself. Some fans might not be present because they
share pins with other functions.
Voltage sensors (also known as IN sensors) report their values in millivolts.
An alarm is triggered if the voltage has crossed a programmable minimum
or maximum limit.
The driver supports automatic fan control mode known as Thermal Cruise.
In this mode, the chip attempts to keep the measured temperature in a
predefined temperature range. If the temperature goes out of range, fan
is driven slower/faster to reach the predefined range again.
The mode works for fan1-fan4. Mapping of temperatures to pwm outputs is as
follows:
temp1 -> pwm1
temp2 -> pwm2
temp3 -> pwm3
prog -> pwm4 (the programmable setting is not supported by the driver)
/sys files
----------
pwm[1-4] - this file stores PWM duty cycle or DC value (fan speed) in range:
0 (stop) to 255 (full)
pwm[1-4]_enable - this file controls mode of fan/temperature control:
* 1 Manual Mode, write to pwm file any value 0-255 (full speed)
* 2 Thermal Cruise
Thermal Cruise mode
-------------------
If the temperature is in the range defined by:
pwm[1-4]_target - set target temperature, unit millidegree Celcius
(range 0 - 127000)
pwm[1-4]_tolerance - tolerance, unit millidegree Celcius (range 0 - 15000)
there are no changes to fan speed. Once the temperature leaves the interval,
fan speed increases (temp is higher) or decreases if lower than desired.
There are defined steps and times, but not exported by the driver yet.
pwm[1-4]_min_output - minimum fan speed (range 1 - 255), when the temperature
is below defined range.
pwm[1-4]_stop_time - how many milliseconds [ms] must elapse to switch
corresponding fan off. (when the temperature was below
defined range).
Note: last two functions are influenced by other control bits, not yet exported
by the driver, so a change might not have any effect.

Some files were not shown because too many files have changed in this diff Show More