Merge Linus' tree.

E: ebs@ebshome.net

W: http://kernel.ebshome.net/

P: 1024D/AE5467F1 FF22 39F1 6728 89F6 6E6C  2365 7602 F33D AE54 67F1

D: Embedded PowerPC 4xx: I2C, PIC and random hacks/fixes

D: Embedded PowerPC 4xx: EMAC, I2C, PIC and random hacks/fixes

S: Sunnyvale, California 94085

S: USA

Eine deutsche Version dieser Datei finden Sie unter

<http://www.stefan-winter.de/Changes-2.4.0.txt>.

Last updated: October 29th, 2002

Chris Ricker (kaboom@gatech.edu or chris.ricker@genetics.utah.edu).

Current Minimal Requirements

hardware, for example, you probably needn't concern yourself with

isdn4k-utils.

o  Gnu C                  2.95.3                  # gcc --version

o  Gnu C                  3.2                     # gcc --version

o  Gnu make               3.79.1                  # make --version

o  binutils               2.12                    # ld -v

o  util-linux             2.10o                   # fdformat --version

---

The gcc version requirements may vary depending on the type of CPU in your

computer. The next paragraph applies to users of x86 CPUs, but not

necessarily to users of other CPUs. Users of other CPUs should obtain

information about their gcc version requirements from another source.

The recommended compiler for the kernel is gcc 2.95.x (x >= 3), and it

should be used when you need absolute stability. You may use gcc 3.0.x

instead if you wish, although it may cause problems. Later versions of gcc 

have not received much testing for Linux kernel compilation, and there are 

almost certainly bugs (mainly, but not exclusively, in the kernel) that

will need to be fixed in order to use these compilers. In any case, using

pgcc instead of plain gcc is just asking for trouble.

The Red Hat gcc 2.96 compiler subtree can also be used to build this tree.

You should ensure you use gcc-2.96-74 or later. gcc-2.96-54 will not build

the kernel correctly.

In addition, please pay attention to compiler optimization.  Anything

greater than -O2 may not be wise.  Similarly, if you choose to use gcc-2.95.x

or derivatives, be sure not to use -fstrict-aliasing (which, depending on

your version of gcc 2.95.x, may necessitate using -fno-strict-aliasing).

computer.

Make

----

Kernel compilation

******************

gcc 2.95.3

----------

o  <ftp://ftp.gnu.org/gnu/gcc/gcc-2.95.3.tar.gz>

gcc

---

o  <ftp://ftp.gnu.org/gnu/gcc/>

Make

----

have a reference count on it, you almost certainly have a bug.

		Chapter 11: Macros, Enums, Inline functions and RTL

		Chapter 11: Macros, Enums and RTL

Names of macros defining constants and labels in enums are capitalized.

language.

		Chapter 14: References

		Chapter 14: The inline disease

There appears to be a common misperception that gcc has a magic "make me

faster" speedup option called "inline". While the use of inlines can be

appropriate (for example as a means of replacing macros, see Chapter 11), it

very often is not. Abundant use of the inline keyword leads to a much bigger

kernel, which in turn slows the system as a whole down, due to a bigger

icache footprint for the CPU and simply because there is less memory

available for the pagecache. Just think about it; a pagecache miss causes a

disk seek, which easily takes 5 miliseconds. There are a LOT of cpu cycles

that can go into these 5 miliseconds.

A reasonable rule of thumb is to not put inline at functions that have more

than 3 lines of code in them. An exception to this rule are the cases where

a parameter is known to be a compiletime constant, and as a result of this

constantness you *know* the compiler will be able to optimize most of your

function away at compile time. For a good example of this later case, see

the kmalloc() inline function.

Often people argue that adding inline to functions that are static and used

only once is always a win since there is no space tradeoff. While this is

technically correct, gcc is capable of inlining these automatically without

help, and the maintenance issue of removing the inline when a second user

appears outweighs the potential value of the hint that tells gcc to do

something it would have done anyway.

		Chapter 15: References

The C Programming Language, Second Edition

by Brian W. Kernighan and Dennis M. Ritchie.

URL: http://cm.bell-labs.com/cm/cs/tpop/

GNU manuals - where in compliance with K&R and this text - for cpp, gcc,

gcc internals and indent, all available from http://www.gnu.org

gcc internals and indent, all available from http://www.gnu.org/manual/

WG14 is the international standardization working group for the programming

language C, URL: http://std.dkuug.dk/JTC1/SC22/WG14/

language C, URL: http://www.open-std.org/JTC1/SC22/WG14/

Kernel CodingStyle, by greg@kroah.com at OLS 2002:

http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/

--

Last updated on 16 February 2004 by a community effort on LKML.

Last updated on 30 December 2005 by a community effort on LKML.

Refcounter framework for elements of lists/arrays protected by

RCU.

Refcounter design for elements of lists/arrays protected by RCU.

Refcounting on elements of  lists which are protected by traditional

reader/writer spinlocks or semaphores are straight forward as in:

If this list/array is made lock free using rcu as in changing the

write_lock in add() and delete() to spin_lock and changing read_lock

in search_and_reference to rcu_read_lock(), the rcuref_get in

in search_and_reference to rcu_read_lock(), the atomic_get in

search_and_reference could potentially hold reference to an element which

has already been deleted from the list/array.  rcuref_lf_get_rcu takes

has already been deleted from the list/array.  atomic_inc_not_zero takes

care of this scenario. search_and_reference should look as;

1.					2.

{					{

    alloc_object			    rcu_read_lock();

    ...					    search_for_element

	atomic_set(&el->rc, 1);			if (rcuref_inc_lf(&el->rc)) {

    atomic_set(&el->rc, 1);		    if (atomic_inc_not_zero(&el->rc)) {

    write_lock(&list_lock);		        rcu_read_unlock();

					        return FAIL;

    add_element				    }

release_referenced()			delete()

{					{

    ...					    write_lock(&list_lock);

	rcuref_dec(&el->rc, relfunc)	...

    atomic_dec(&el->rc, relfunc)	    ...

    ...					    delete_element

}					    write_unlock(&list_lock);

 					    ...

					if (rcuref_dec_and_test(&el->rc))

					    if (atomic_dec_and_test(&el->rc))

					        call_rcu(&el->head, el_free);

					    ...

					}

Sometimes, reference to the element need to be obtained in the

update (write) stream.  In such cases, rcuref_inc_lf might be an overkill

since the spinlock serialising list updates are held. rcuref_inc

update (write) stream.  In such cases, atomic_inc_not_zero might be an

overkill since the spinlock serialising list updates are held. atomic_inc

is to be used in such cases.

For arches which do not have cmpxchg rcuref_inc_lf

api uses a hashed spinlock implementation and the same hashed spinlock

is acquired in all rcuref_xxx primitives to preserve atomicity.

Note: Use rcuref_inc api only if you need to use rcuref_inc_lf on the

refcounter atleast at one place.  Mixing rcuref_inc and atomic_xxx api

might lead to races. rcuref_inc_lf() must be used in lockfree

RCU critical sections only.

------------------------

Linux 2.0:

	No new drivers are accepted for this kernel tree

	No new drivers are accepted for this kernel tree.

Linux 2.2:

	No new drivers are accepted for this kernel tree.

Linux 2.4:

	If the code area has a general maintainer then please submit it to

	the maintainer listed in MAINTAINERS in the kernel file. If the

	maintainer does not respond or you cannot find the appropriate

	maintainer then please contact the 2.2 kernel maintainer:

	Marc-Christian Petersen <m.c.p@wolk-project.de>.

Linux 2.4:

	The same rules apply as 2.2. The final contact point for Linux 2.4

	submissions is Marcelo Tosatti <marcelo.tosatti@cyclades.com>.

	maintainer then please contact Marcelo Tosatti

	<marcelo.tosatti@cyclades.com>.

Linux 2.6:

	The same rules apply as 2.4 except that you should follow linux-kernel

		of exclusive GPL licensing, and if you wish the driver

		to be useful to other communities such as BSD you may well

		wish to release under multiple licenses.

		See accepted licenses at include/linux/module.h

Copyright:	The copyright owner must agree to use of GPL.

		It's best if the submitter and copyright owner

	http://kernelnewbies.org/

Linux USB project:

	http://sourceforge.net/projects/linux-usb/

	http://linux-usb.sourceforge.net/

How to NOT write kernel driver by arjanv@redhat.com

	http://people.redhat.com/arjanv/olspaper.pdf

Kernel Janitor:

	http://janitor.kernelnewbies.org/

--

Last updated on 17 Nov 2005.