Merge rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6

# quilt's files

patches

series

# cscope files

cscope.*

S: USA

N: Lennert Buytenhek

E: buytenh@gnu.org

D: Rewrite of the ethernet bridging code

S: Ravenhorst 58B

E: kernel@wantstofly.org

D: Original (2.4) rewrite of the ethernet bridging code

D: Various ARM bits and pieces

S: Ravenhorst 58

S: 2317 AK Leiden

S: The Netherlands

S: 1098 VA Amsterdam 

S: The Netherlands

N: Jiri Kosina

E: jikos@jikos.cz

E: jkosina@suse.cz

D: Generic HID layer - original code split, fixes

D: Various ACPI fixes, keeping correct battery state through suspend

D: various lockdep annotations, autofs and other random bugfixes

S: Prague, Czech Republic

N: Gene Kozin

E: 74604.152@compuserve.com

W: http://www.sangoma.com

S: Spain

N: Linus Torvalds

E: torvalds@osdl.org

E: torvalds@linux-foundation.org

D: Original kernel hacker

S: 12725 SW Millikan Way, Suite 400

S: Beaverton, Oregon 97005

What:           /debug/pktcdvd/pktcdvd[0-7]

Date:           Oct. 2006

KernelVersion:  2.6.19

Contact:        Thomas Maier <balagi@justmail.de>

Description:

debugfs interface

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

The pktcdvd module (packet writing driver) creates

these files in debugfs:

/debug/pktcdvd/pktcdvd[0-7]/

    info            (0444) Lots of human readable driver

                           statistics and infos. Multiple lines!

Example:

-------

cat /debug/pktcdvd/pktcdvd0/info

What:           /sys/class/pktcdvd/

Date:           Oct. 2006

KernelVersion:  2.6.19

Contact:        Thomas Maier <balagi@justmail.de>

Description:

sysfs interface

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

The pktcdvd module (packet writing driver) creates

these files in the sysfs:

(<devid> is in format  major:minor )

/sys/class/pktcdvd/

    add            (0200)  Write a block device id (major:minor)

                           to create a new pktcdvd device and map

                           it to the block device.

    remove         (0200)  Write the pktcdvd device id (major:minor)

                           to it to remove the pktcdvd device.

    device_map     (0444)  Shows the device mapping in format:

                             pktcdvd[0-7] <pktdevid> <blkdevid>

/sys/class/pktcdvd/pktcdvd[0-7]/

    dev                   (0444) Device id

    uevent                (0200) To send an uevent.

/sys/class/pktcdvd/pktcdvd[0-7]/stat/

    packets_started       (0444) Number of started packets.

    packets_finished      (0444) Number of finished packets.

    kb_written            (0444) kBytes written.

    kb_read               (0444) kBytes read.

    kb_read_gather        (0444) kBytes read to fill write packets.

    reset                 (0200) Write any value to it to reset

                                 pktcdvd device statistic values, like

                                 bytes read/written.

/sys/class/pktcdvd/pktcdvd[0-7]/write_queue/

    size                  (0444) Contains the size of the bio write

                                 queue.

    congestion_off        (0644) If bio write queue size is below

                                 this mark, accept new bio requests

                                 from the block layer.

    congestion_on         (0644) If bio write queue size is higher

                                 as this mark, do no longer accept

                                 bio write requests from the block

                                 layer and wait till the pktcdvd

                                 device has processed enough bio's

                                 so that bio write queue size is

                                 below congestion off mark.

                                 A value of <= 0 disables congestion

                                 control.

Example:

--------

To use the pktcdvd sysfs interface directly, you can do:

# create a new pktcdvd device mapped to /dev/hdc

echo "22:0" >/sys/class/pktcdvd/add

cat /sys/class/pktcdvd/device_map

# assuming device pktcdvd0 was created, look at stat's

cat /sys/class/pktcdvd/pktcdvd0/stat/kb_written

# print the device id of the mapped block device

fgrep pktcdvd0 /sys/class/pktcdvd/device_map

# remove device, using pktcdvd0 device id   253:0

echo "253:0" >/sys/class/pktcdvd/remove

benefit of warning you when you're nesting your functions too deep.

Heed that warning.

The preferred way to ease multiple indentation levels in a switch statement is

to align the "switch" and its subordinate "case" labels in the same column

instead of "double-indenting" the "case" labels.  E.g.:

	switch (suffix) {

	case 'G':

	case 'g':

		mem <<= 30;

		break;

	case 'M':

	case 'm':

		mem <<= 20;

		break;

	case 'K':

	case 'k':

		mem <<= 10;

		/* fall through */

	default:

		break;

	}

Don't put multiple statements on a single line unless you have

something to hide:

	if (condition) do_this;

	  do_something_everytime;

Don't put multiple assignments on a single line either.  Kernel coding style

is super simple.  Avoid tricky expressions.

Outside of comments, documentation and except in Kconfig, spaces are never

used for indentation, and the above example is deliberately broken.

		next_statement;

}

		Chapter 3: Placing Braces

		Chapter 3: Placing Braces and Spaces

The other issue that always comes up in C styling is the placement of

braces.  Unlike the indent size, there are few technical reasons to

		we do y

	}

This applies to all non-function statement blocks (if, switch, for,

while, do).  E.g.:

	switch (action) {

	case KOBJ_ADD:

		return "add";

	case KOBJ_REMOVE:

		return "remove";

	case KOBJ_CHANGE:

		return "change";

	default:

		return NULL;

	}

However, there is one special case, namely functions: they have the

opening brace at the beginning of the next line, thus:

25-line terminal screens here), you have more empty lines to put

comments on.

		3.1:  Spaces

Linux kernel style for use of spaces depends (mostly) on

function-versus-keyword usage.  Use a space after (most) keywords.  The

notable exceptions are sizeof, typeof, alignof, and __attribute__, which look

somewhat like functions (and are usually used with parentheses in Linux,

although they are not required in the language, as in: "sizeof info" after

"struct fileinfo info;" is declared).

So use a space after these keywords:

	if, switch, case, for, do, while

but not with sizeof, typeof, alignof, or __attribute__.  E.g.,

	s = sizeof(struct file);

Do not add spaces around (inside) parenthesized expressions.  This example is

*bad*:

	s = sizeof( struct file );

When declaring pointer data or a function that returns a pointer type, the

preferred use of '*' is adjacent to the data name or function name and not

adjacent to the type name.  Examples:

	char *linux_banner;

	unsigned long long memparse(char *ptr, char **retptr);

	char *match_strdup(substring_t *s);

Use one space around (on each side of) most binary and ternary operators,

such as any of these:

	=  +  -  <  >  *  /  %  |  &  ^  <=  >=  ==  !=  ?  :

but no space after unary operators:

	&  *  +  -  ~  !  sizeof  typeof  alignof  __attribute__  defined

no space before the postfix increment & decrement unary operators:

	++  --

no space after the prefix increment & decrement unary operators:

	++  --

and no space around the '.' and "->" structure member operators.

		Chapter 4: Naming

If you are afraid to mix up your local variable names, you have another

problem, which is called the function-growth-hormone-imbalance syndrome.

See next chapter.

See chapter 6 (Functions).

		Chapter 5: Typedefs

and it gets confused.  You know you're brilliant, but maybe you'd like

to understand what you did 2 weeks from now.

In source files, separate functions with one blank line.  If the function is

exported, the EXPORT* macro for it should follow immediately after the closing

function brace line.  E.g.:

int system_is_up(void)

{

	return system_state == SYSTEM_RUNNING;

}

EXPORT_SYMBOL(system_is_up);

In function prototypes, include parameter names with their data types.

Although this is not required by the C language, it is preferred in Linux

because it is a simple way to add valuable information for the reader.

		Chapter 7: Centralized exiting of functions

Generally, you want your comments to tell WHAT your code does, not HOW.

Also, try to avoid putting comments inside a function body: if the

function is so complex that you need to separately comment parts of it,

you should probably go back to chapter 5 for a while.  You can make

you should probably go back to chapter 6 for a while.  You can make

small comments to note or warn about something particularly clever (or

ugly), but try to avoid excess.  Instead, put the comments at the head

of the function, telling people what it does, and possibly WHY it does

it.

When commenting the kernel API functions, please use the kerneldoc format.

When commenting the kernel API functions, please use the kernel-doc format.

See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc

for details.

Linux style for comments is the C89 "/* ... */" style.

Don't use C99-style "// ..." comments.

The preferred style for long (multi-line) comments is:

	/*

	 * This is the preferred style for multi-line

	 * comments in the Linux kernel source code.

	 * Please use it consistently.

	 *

	 * Description:  A column of asterisks on the left side,

	 * with beginning and ending almost-blank lines.

	 */

It's also important to comment data, whether they are basic types or derived

types.  To this end, use just one data declaration per line (no commas for

multiple data declarations).  This leaves you room for a small comment on each

item, explaining its use.

		Chapter 9: You've made a mess of it

That's OK, we all do.  You've probably been told by your long-time Unix

NULL or the ERR_PTR mechanism to report failure.

		Chapter 17:  Don't re-invent the kernel macros

The header file include/linux/kernel.h contains a number of macros that

you should use, rather than explicitly coding some variant of them yourself.

For example, if you need to calculate the length of an array, take advantage

of the macro

  #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))

Similarly, if you need to calculate the size of some structure member, use

  #define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))

There are also min() and max() macros that do strict type checking if you

need them.  Feel free to peruse that header file to see what else is already

defined that you shouldn't reproduce in your code.

		Appendix I: References

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

--

Last updated on 30 April 2006.

Last updated on 2006-December-06.