Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 59458f40 authored by Steven Whitehouse's avatar Steven Whitehouse
Browse files

Merge branch 'master' into gfs2

parents 825f9075 d834c165

CREDITS

+4 −2
Original line number Diff line number Diff line
@@ -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 −0
Original line number Diff line number Diff line
@@ -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
Original line number Diff line number Diff line
@@ -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 −0
Original line number Diff line number Diff line
@@ -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
Original line number Diff line number Diff line
@@ -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.