Merge with /pub/scm/linux/kernel/git/torvalds/linux-2.6.git

*.a

*.s

*.ko

*.so

*.mod.c

#

# Generated include files

#

include/asm

include/asm-*/asm-offsets.h

include/config

include/linux/autoconf.h

include/linux/compile.h

E: jayalk@intworks.biz

W: http://www.intworks.biz

D: Arc monochrome LCD framebuffer driver, x86 reboot fixups

D: pirq addr, CS5535 alsa audio driver

S: Gurgaon, India

S: Kuala Lumpur, Malaysia

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

----

    modifications are prevented

- saves the compiler work to optimize redundant code away ;)

int fun(int )

int fun(int a)

{

	int result = 0;

	char *buffer = kmalloc(SIZE);

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.

*.xml

*.ps

*.pdf

*.html

*.9.gz

*.9