Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 44021
b: refs/heads/master
c: 45a9b83
h: refs/heads/master
i:
  44019: 8901863
v: v3
  • Loading branch information
Patrick Boettcher authored and Mauro Carvalho Chehab committed Dec 10, 2006
1 parent b91f914 commit 581c560
Show file tree
Hide file tree
Showing 212 changed files with 9,606 additions and 15,711 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7
refs/heads/master: 45a9b83fe4cf91b13900dc665f526f7fd94d484c
126 changes: 5 additions & 121 deletions trunk/Documentation/CodingStyle
Original file line number Diff line number Diff line change
Expand Up @@ -35,37 +35,12 @@ In short, 8-char indents make things easier to read, and have the added
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.

Expand Down Expand Up @@ -94,7 +69,7 @@ void fun(int a, int b, int c)
next_statement;
}

Chapter 3: Placing Braces and Spaces
Chapter 3: Placing Braces

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
Expand All @@ -106,20 +81,6 @@ brace last on the line, and put the closing brace first, thusly:
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:

Expand Down Expand Up @@ -160,49 +121,6 @@ supply of new-lines on your screen is not a renewable resource (think
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

Expand Down Expand Up @@ -234,7 +152,7 @@ variable that is used to hold a temporary value.

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 chapter 6 (Functions).
See next chapter.


Chapter 5: Typedefs
Expand Down Expand Up @@ -340,20 +258,6 @@ generally easily keep track of about 7 different things, anything more
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

Expand Down Expand Up @@ -402,36 +306,16 @@ time to explain badly written code.
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 6 for a while. You can make
you should probably go back to chapter 5 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 kernel-doc format.
When commenting the kernel API functions, please use the kerneldoc 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
Expand Down Expand Up @@ -707,4 +591,4 @@ Kernel CodingStyle, by greg@kroah.com at OLS 2002:
http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/

--
Last updated on 2006-December-06.
Last updated on 30 April 2006.
6 changes: 0 additions & 6 deletions trunk/Documentation/SubmitChecklist
Original file line number Diff line number Diff line change
Expand Up @@ -66,9 +66,3 @@ kernel patches.
See Documentation/ABI/README for more information.

20: Check that it all passes `make headers_check'.

21: Has been checked with injection of at least slab and page-allocation
fauilures. See Documentation/fault-injection/.

If the new code is substantial, addition of subsystem-specific fault
injection might be appropriate.
64 changes: 18 additions & 46 deletions trunk/Documentation/accounting/getdelays.c
Original file line number Diff line number Diff line change
Expand Up @@ -7,8 +7,6 @@
* Copyright (C) Balbir Singh, IBM Corp. 2006
* Copyright (c) Jay Lan, SGI. 2006
*
* Compile with
* gcc -I/usr/src/linux/include getdelays.c -o getdelays
*/

#include <stdio.h>
Expand Down Expand Up @@ -37,20 +35,13 @@
#define NLA_DATA(na) ((void *)((char*)(na) + NLA_HDRLEN))
#define NLA_PAYLOAD(len) (len - NLA_HDRLEN)

#define err(code, fmt, arg...) \
do { \
fprintf(stderr, fmt, ##arg); \
exit(code); \
} while (0)

int done;
int rcvbufsz;
char name[100];
int dbg;
int print_delays;
int print_io_accounting;
__u64 stime, utime;
#define err(code, fmt, arg...) do { printf(fmt, ##arg); exit(code); } while (0)
int done = 0;
int rcvbufsz=0;

char name[100];
int dbg=0, print_delays=0;
__u64 stime, utime;
#define PRINTF(fmt, arg...) { \
if (dbg) { \
printf(fmt, ##arg); \
Expand Down Expand Up @@ -87,9 +78,8 @@ static int create_nl_socket(int protocol)
if (rcvbufsz)
if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF,
&rcvbufsz, sizeof(rcvbufsz)) < 0) {
fprintf(stderr, "Unable to set socket rcv buf size "
"to %d\n",
rcvbufsz);
printf("Unable to set socket rcv buf size to %d\n",
rcvbufsz);
return -1;
}

Expand Down Expand Up @@ -196,15 +186,6 @@ void print_delayacct(struct taskstats *t)
"count", "delay total", t->swapin_count, t->swapin_delay_total);
}

void print_ioacct(struct taskstats *t)
{
printf("%s: read=%llu, write=%llu, cancelled_write=%llu\n",
t->ac_comm,
(unsigned long long)t->read_bytes,
(unsigned long long)t->write_bytes,
(unsigned long long)t->cancelled_write_bytes);
}

int main(int argc, char *argv[])
{
int c, rc, rep_len, aggr_len, len2, cmd_type;
Expand All @@ -227,7 +208,7 @@ int main(int argc, char *argv[])
struct msgtemplate msg;

while (1) {
c = getopt(argc, argv, "diw:r:m:t:p:v:l");
c = getopt(argc, argv, "dw:r:m:t:p:v:l");
if (c < 0)
break;

Expand All @@ -236,10 +217,6 @@ int main(int argc, char *argv[])
printf("print delayacct stats ON\n");
print_delays = 1;
break;
case 'i':
printf("printing IO accounting\n");
print_io_accounting = 1;
break;
case 'w':
strncpy(logfile, optarg, MAX_FILENAME);
printf("write to file %s\n", logfile);
Expand All @@ -261,12 +238,14 @@ int main(int argc, char *argv[])
if (!tid)
err(1, "Invalid tgid\n");
cmd_type = TASKSTATS_CMD_ATTR_TGID;
print_delays = 1;
break;
case 'p':
tid = atoi(optarg);
if (!tid)
err(1, "Invalid pid\n");
cmd_type = TASKSTATS_CMD_ATTR_PID;
print_delays = 1;
break;
case 'v':
printf("debug on\n");
Expand Down Expand Up @@ -298,7 +277,7 @@ int main(int argc, char *argv[])
mypid = getpid();
id = get_family_id(nl_sd);
if (!id) {
fprintf(stderr, "Error getting family id, errno %d\n", errno);
printf("Error getting family id, errno %d", errno);
goto err;
}
PRINTF("family id %d\n", id);
Expand All @@ -309,7 +288,7 @@ int main(int argc, char *argv[])
&cpumask, strlen(cpumask) + 1);
PRINTF("Sent register cpumask, retval %d\n", rc);
if (rc < 0) {
fprintf(stderr, "error sending register cpumask\n");
printf("error sending register cpumask\n");
goto err;
}
}
Expand All @@ -319,7 +298,7 @@ int main(int argc, char *argv[])
cmd_type, &tid, sizeof(__u32));
PRINTF("Sent pid/tgid, retval %d\n", rc);
if (rc < 0) {
fprintf(stderr, "error sending tid/tgid cmd\n");
printf("error sending tid/tgid cmd\n");
goto done;
}
}
Expand All @@ -331,15 +310,13 @@ int main(int argc, char *argv[])
PRINTF("received %d bytes\n", rep_len);

if (rep_len < 0) {
fprintf(stderr, "nonfatal reply error: errno %d\n",
errno);
printf("nonfatal reply error: errno %d\n", errno);
continue;
}
if (msg.n.nlmsg_type == NLMSG_ERROR ||
!NLMSG_OK((&msg.n), rep_len)) {
struct nlmsgerr *err = NLMSG_DATA(&msg);
fprintf(stderr, "fatal reply error, errno %d\n",
err->error);
printf("fatal reply error, errno %d\n", err->error);
goto done;
}

Expand Down Expand Up @@ -379,8 +356,6 @@ int main(int argc, char *argv[])
count++;
if (print_delays)
print_delayacct((struct taskstats *) NLA_DATA(na));
if (print_io_accounting)
print_ioacct((struct taskstats *) NLA_DATA(na));
if (fd) {
if (write(fd, NLA_DATA(na), na->nla_len) < 0) {
err(1,"write error\n");
Expand All @@ -390,9 +365,7 @@ int main(int argc, char *argv[])
goto done;
break;
default:
fprintf(stderr, "Unknown nested"
" nla_type %d\n",
na->nla_type);
printf("Unknown nested nla_type %d\n", na->nla_type);
break;
}
len2 += NLA_ALIGN(na->nla_len);
Expand All @@ -401,8 +374,7 @@ int main(int argc, char *argv[])
break;

default:
fprintf(stderr, "Unknown nla_type %d\n",
na->nla_type);
printf("Unknown nla_type %d\n", na->nla_type);
break;
}
na = (struct nlattr *) (GENLMSG_DATA(&msg) + len);
Expand Down
Loading

0 comments on commit 581c560

Please sign in to comment.