Merge branch 'master' into upstream

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

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

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

     </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>

     </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>

     </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

-->

!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

!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/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.

		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

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:

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.