Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history 
yaml
---
r: 38231
b: refs/heads/master
c: 63c422a
h: refs/heads/master
i:
  38229: 9f61ab5
  38227: d533705
  38223: dbc759d
v: v3
  • Loading branch information
Linus Torvalds committed Oct 3, 2006
1 parent 3abc4fd commit 50491c4
Show file tree
Hide file tree
Showing 2,192 changed files with 59,827 additions and 41,378 deletions.
2 changes: 1 addition & 1 deletion [refs]
View file
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: d14b272bc63f35a8f20b4b1df16c080b8d24f8f1
refs/heads/master: 63c422afe3739b68bec0b5c42807d1450c951caf
12 changes: 10 additions & 2 deletions trunk/CREDITS
View file
Original file line number Diff line number Diff line change
Expand Up @@ -951,6 +951,12 @@ S: Brevia 1043
S: S-114 79 Stockholm
S: Sweden

N: Pekka Enberg
E: penberg@cs.helsinki.fi
W: http://www.cs.helsinki.fi/u/penberg/
D: Various kernel hacks, fixes, and cleanups.
S: Finland

N: David Engebretsen
E: engebret@us.ibm.com
D: Linux port to 64-bit PowerPC architecture
Expand Down Expand Up @@ -1620,7 +1626,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
Expand Down Expand Up @@ -2477,7 +2484,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
Expand Down
34 changes: 34 additions & 0 deletions trunk/Documentation/CodingStyle
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
83 changes: 55 additions & 28 deletions trunk/Documentation/DocBook/kernel-api.tmpl
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Expand Down Expand Up @@ -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>
Expand Down Expand Up @@ -302,8 +325,13 @@ X!Ekernel/module.c
!Ekernel/irq/manage.c
</sect1>

<sect1><title>DMA Channels</title>
!Ekernel/dma.c
</sect1>

<sect1><title>Resources Management</title>
!Ikernel/resource.c
!Ekernel/resource.c
</sect1>

<sect1><title>MTRR Handling</title>
Expand Down Expand Up @@ -349,13 +377,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
Expand Down Expand Up @@ -386,6 +407,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
Expand Down Expand Up @@ -437,6 +459,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
Expand Down
20 changes: 20 additions & 0 deletions trunk/Documentation/HOWTO
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
-------------

Expand Down
19 changes: 15 additions & 4 deletions trunk/Documentation/IPMI.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down Expand Up @@ -361,6 +364,7 @@ You can change this at module load time (for a module) with:
regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
regshifts=<shift1>,<shift2>,...
slave_addrs=<addr1>,<addr2>,...
force_kipmid=<enable1>,<enable2>,...

Each of these except si_trydefaults is a list, the first item for the
first interface, second item for the second interface, etc.
Expand Down Expand Up @@ -406,7 +410,13 @@ The slave_addrs specifies the IPMI address of the local BMC. This is
usually 0x20 and the driver defaults to that, but in case it's not, it
can be specified when the driver starts up.

When compiled into the kernel, the addresses can be specified on the
The force_ipmid parameter forcefully enables (if set to 1) or disables
(if set to 0) the kernel IPMI daemon. Normally this is auto-detected
by the driver, but systems with broken interrupts might need an enable,
or users that don't want the daemon (don't need the performance, don't
want the CPU hit) can disable it.

When compiled into the kernel, the parameters can be specified on the
kernel command line as:

ipmi_si.type=<type1>,<type2>...
Expand All @@ -416,6 +426,7 @@ kernel command line as:
ipmi_si.regsizes=<size1>,<size2>,...
ipmi_si.regshifts=<shift1>,<shift2>,...
ipmi_si.slave_addrs=<addr1>,<addr2>,...
ipmi_si.force_kipmid=<enable1>,<enable2>,...

It works the same as the module parameters of the same names.

Expand Down
5 changes: 5 additions & 0 deletions trunk/Documentation/SubmitChecklist
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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'.
21 changes: 7 additions & 14 deletions trunk/Documentation/SubmittingDrivers
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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,
Expand All @@ -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,
Expand All @@ -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:
Expand All @@ -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.
Loading

0 comments on commit 50491c4

Please sign in to comment.