coding standard related work for Linux kernel code using checkpatch.pl tool

$git fetch origin
$
$./scripts/checkpatch.pl --file --terse sound/sound_core.c | more
sound/sound_core.c:71: ERROR: trailing whitespace
sound/sound_core.c:83: ERROR: trailing whitespace
sound/sound_core.c:85: ERROR: trailing whitespace
sound/sound_core.c:115: ERROR: open brace '{' following
struct go on the same line
sound/sound_core.c:123: WARNING: externs should be avoided in .c files
sound/sound_core.c:126: WARNING: externs should be avoided in .c files
sound/sound_core.c:155: ERROR: do not initialise statics to 0 or NULL
sound/sound_core.c:163: ERROR: that open brace { should be on the
previous line
sound/sound_core.c:175: WARNING: line over 80 characters
.
.
.
.
.
.
sound/sound_core.c:586: ERROR: trailing whitespace
sound/sound_core.c:633: ERROR: space required after that ',' (ctx:VxV)
total: 77 errors, 26 warnings, 667 lines checked
.
.
. 
.
.
.
total: 73 errors, 26 warnings, 666 lines checked

As an  alternative to  automatic variables, it  is possible  to define
variables that are external to  all functions, that is, variables that
can be  accessed by  name by any  function. (This mechanism  is rather
like  Fortran COMMON  or Pascal  variables declared  in  the outermost
block.) Because  external variables are globally  accessible, they can
be  used  instead  of  argument  lists  to  communicate  data  between
functions. Furthermore, because external variables remain in existence
permanently, rather  than appearing and disappearing  as functions are
called and exited,  they retain their values even  after the functions
that set them have returned.

.
.
. 
.
total: 28 errors, 23 warnings, 663 lines checked

$./scripts/checkpatch.pl --file --terse sound/sound_core.c
sound/sound_core.c:122: WARNING: externs should be avoided in .c files
sound/sound_core.c:125: WARNING: externs should be avoided in .c files
 .
.
.
.
.
total: 0 errors, 11 warnings, 662 lines checked
$

kernel work log sound 0.11

$git fetch origin
$
$./scripts/checkpatch.pl --file --terse sound/sound_core.c | more
sound/sound_core.c:71: ERROR: trailing whitespace
sound/sound_core.c:83: ERROR: trailing whitespace
sound/sound_core.c:85: ERROR: trailing whitespace
sound/sound_core.c:115: ERROR: open brace '{' following
struct go on the same line
sound/sound_core.c:123: WARNING: externs should be avoided in .c files
sound/sound_core.c:126: WARNING: externs should be avoided in .c files
sound/sound_core.c:155: ERROR: do not initialise statics to 0 or NULL
sound/sound_core.c:163: ERROR: that open brace { should be on the
previous line
sound/sound_core.c:175: WARNING: line over 80 characters
.
.
.
.
.
.
sound/sound_core.c:586: ERROR: trailing whitespace
sound/sound_core.c:633: ERROR: space required after that ',' (ctx:VxV)
total: 77 errors, 26 warnings, 667 lines checked
.
.
. <fixing>
.
.
.
total: 73 errors, 26 warnings, 666 lines checked


As an  alternative to  automatic variables, it  is possible  to define
variables that are external to  all functions, that is, variables that
can be  accessed by  name by any  function. (This mechanism  is rather
like  Fortran COMMON  or Pascal  variables declared  in  the outermost
block.) Because  external variables are globally  accessible, they can
be  used  instead  of  argument  lists  to  communicate  data  between
functions. Furthermore, because external variables remain in existence
permanently, rather  than appearing and disappearing  as functions are
called and exited,  they retain their values even  after the functions
that set them have returned.

 
.
.
. < fixing >
.
total: 28 errors, 23 warnings, 663 lines checked

$./scripts/checkpatch.pl --file --terse sound/sound_core.c
sound/sound_core.c:122: WARNING: externs should be avoided in .c files
sound/sound_core.c:125: WARNING: externs should be avoided in .c files
 .
.
.
.
.
total: 0 errors, 11 warnings, 662 lines checked
$

Some idea about creating a linux kernel patch using Git

ABOUT creating a linux kernel patch using Git
[bash]
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Initialized empty Git repository in /home/jeffrin/linux-2.6/.git/
remote: Counting objects: 1806930, done.
remote: Compressing objects: 100% (278260/278260), done.
Receiving objects: 14% (2553100/1806930), 117.83 MiB | 127 KiB/s
Resolving deltas: 100% (1513210/1513210), done.

$cd linux-2.6
$./scripts/ge
genksyms/ get_maintainer.pl

$./scripts/get_maintainer.pl –file sound/ac97_bus.c
Jaroslav Kysela <perex@perex.cz>
Takashi Iwai <tiwai@suse.de>
alsa-devel@alsa-project.org
linux-kernel@vger.kernel.org
$

[/bash]

[bash]

$ git status
# On branch master
nothing to commit (working directory clean)
$ git branch jeffrin
$ git branch
jeffrin
* master
$ git checkout jeffrin
Switched to branch ‘jeffrin’
$
$git status
# On branch jeffrin
nothing to commit (working directory clean)
$
$./scripts/checkpatch.pl
checkpatch.pl: no input files
$./scripts/checkpatch.pl –file –terse sound/ac97_bus.c
sound/ac97_bus.c:22: WARNING: line over 80 characters
sound/ac97_bus.c:75: WARNING: EXPORT_SYMBOL(foo); should immediately
follow its function/variable
total: 0 errors, 2 warnings, 77 lines checked
[/bash]
[bash]
$vim sound/ac97_bus.c +22
$./scripts/checkpatch.pl –file –terse sound/ac97_bus.c
sound/ac97_bus.c:22: ERROR: trailing whitespace
sound/ac97_bus.c:75: WARNING: EXPORT_SYMBOL(foo); should immediately
follow its function/variable
total: 1 errors, 1 warnings, 77 lines checked
$vim sound/ac97_bus.c +22
$./scripts/checkpatch.pl –file –terse sound/ac97_bus.c
sound/ac97_bus.c:75: WARNING: EXPORT_SYMBOL(foo); should immediately
follow its function/variable
total: 0 errors, 1 warnings, 77 lines checked
$vim sound/ac97_bus.c +75
[/bash]
[bash]
$git status
# On branch jeffrin
# Changed but not updated:
# (use "git add …" to update what will be committed)
# (use "git checkout — …" to discard changes in working directory)
#
# modified: sound/ac97_bus.c
#
no changes added to commit (use "git add" and/or "git commit -a")
$git diff
diff –git a/sound/ac97_bus.c b/sound/ac97_bus.c
index a351dd0..c93251a 100644
— a/sound/ac97_bus.c
+++ b/sound/ac97_bus.c
@@ -19,9 +19,9 @@

/*
* Let drivers decide whether they want to support given codec from their
– * probe method. Drivers have direct access to the struct snd_ac97 structure and may
– * decide based on the id field amongst other things.
– */
+ * probe method. Drivers have direct access to the struct snd_ac97
+ * structure and may decide based on the id field amongst other things.
+*/
static int ac97_bus_match(struct device *dev, struct device_driver *drv)
{
return 1;
$
[/bash]

[bash]

$git commit sound/ac97_bus.c
[jeffrin a2c2867] sound: Fixed line limit issue in sound/ac97_bus.c
This is a patch to the sound/ac97_bus.c file that fixes up a 80
character line limit issue found by the checkpatch.pl tool.
Signed-off-by: Jeffrin Jose
1 files changed, 3 insertions(+), 3 deletions(-)
$git show HEAD
commit a2c2867876c246420a199a0fb4c36ad29100a42cc
Author: Jeffrin Jose
Date: Mon Dec 6 19:27:53 2010 +0530

sound: Fixed line limit issue in sound/ac97_bus.c
This is a patch to the sound/ac97_bus.c file that fixes up a 80 character
line limit issue found by the checkpatch.pl tool.
Signed-off-by: Jeffrin Jose

diff –git a/sound/ac97_bus.c b/sound/ac97_bus.c
index a351dd0..c93251a 100644
— a/sound/ac97_bus.c
+++ b/sound/ac97_bus.c
@@ -19,9 +19,9 @@

/*
* Let drivers decide whether they want to support given codec from their
– * probe method. Drivers have direct access to the struct snd_ac97 structure and may
– * decide based on the id field amongst other things.
– */
+ * probe method. Drivers have direct access to the struct snd_ac97
+ * structure and may decide based on the id field amongst other things.
+*/
static int ac97_bus_match(struct device *dev, struct device_driver *drv)
{
return 1;
[/bash]
[bash]
$git format-patch master..jeffrin
0001-sound-Fixed-line-limit-issue-in-sound-ac97_bus.c.patch
[/bash]
[bash]
$./scripts/checkpatch.pl 0001-sound-Fixed-line-limit-issue-in-sound-ac97_bus.c.patch
total: 0 errors, 0 warnings, 12 lines checked

0001-sound-Fixed-line-limit-issue-in-sound-ac97_bus.c.patch has no obvious style
problems and is ready for submission.
$
[/bash]

write linux kernel patch 0.23 raw

 write linux kernel patch 0.21  raw
Content

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Initialized empty Git repository in /home/jeffrin/linux-2.6/.git/
remote: Counting objects: 1806930, done.
remote: Compressing objects: 100% (278260/278260), done.
Receiving objects:  14% (255365/1806930), 117.83 MiB | 127 KiB/s
Resolving deltas: 100% (1513210/1513210), done.



$cd linux-2.6
$./scripts/ge
genksyms/          get_maintainer.pl

$./scripts/get_maintainer.pl --file sound/ac97_bus.c
Jaroslav Kysela <perex@perex.cz>
Takashi Iwai <tiwai@suse.de>
alsa-devel@alsa-project.org
linux-kernel@vger.kernel.org
$





$ git status
# On branch master
nothing to commit (working directory clean)
$ git branch jeffrin
$ git branch
  jeffrin
* master
$ git checkout jeffrin
Switched to branch 'jeffrin'
$
$git status
# On branch jeffrin
nothing to commit (working directory clean)
$
$./scripts/checkpatch.pl
checkpatch.pl: no input files
$./scripts/checkpatch.pl --file --terse sound/ac97_bus.c
sound/ac97_bus.c:22: WARNING: line over 80 characters
sound/ac97_bus.c:75: WARNING: EXPORT_SYMBOL(foo); should immediately
follow its function/variable
total: 0 errors, 2 warnings, 77 lines checked




$vim sound/ac97_bus.c +22
$./scripts/checkpatch.pl --file --terse sound/ac97_bus.c
sound/ac97_bus.c:22: ERROR: trailing whitespace
sound/ac97_bus.c:75: WARNING: EXPORT_SYMBOL(foo); should immediately
follow its function/variable
total: 1 errors, 1 warnings, 77 lines checked
$vim sound/ac97_bus.c +22
$./scripts/checkpatch.pl --file --terse sound/ac97_bus.c
sound/ac97_bus.c:75: WARNING: EXPORT_SYMBOL(foo); should immediately
follow its function/variable
total: 0 errors, 1 warnings, 77 lines checked
$vim sound/ac97_bus.c +75




$git status
# On branch jeffrin
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#	modified:   sound/ac97_bus.c
#
no changes added to commit (use "git add" and/or "git commit -a")
$git diff
diff --git a/sound/ac97_bus.c b/sound/ac97_bus.c
index a351dd0..c93251a 100644
--- a/sound/ac97_bus.c
+++ b/sound/ac97_bus.c
@@ -19,9 +19,9 @@

 /*
  * Let drivers decide whether they want to support given codec from their
- * probe method.  Drivers have direct access to the struct snd_ac97 structure and may
- * decide based on the id field amongst other things.
- */
+ * probe method. Drivers have direct access to the struct snd_ac97
+ * structure and may  decide based on the id field amongst other things.
+*/
 static int ac97_bus_match(struct device *dev, struct device_driver *drv)
 {
        return 1;
$





$git commit sound/ac97_bus.c
[jeffrin a2c2867] sound: Fixed line limit issue in sound/ac97_bus.c
This is a patch to the sound/ac97_bus.c file that fixes up a 80
character line limit issue found by the checkpatch.pl tool.
Signed-off-by: Jeffrin Jose 
 1 files changed, 3 insertions(+), 3 deletions(-)
$git show HEAD
commit a2c2867876c246420a199a0fb4c36ad2965a42cc
Author: Jeffrin Jose 
Date:   Mon Dec 6 19:27:53 2010 +0530

    sound: Fixed line limit issue in sound/ac97_bus.c
    This is a patch to the sound/ac97_bus.c file that fixes up a 80 character
    line limit issue found by the checkpatch.pl tool.
    Signed-off-by: Jeffrin Jose 

diff --git a/sound/ac97_bus.c b/sound/ac97_bus.c
index a351dd0..c93251a 100644
--- a/sound/ac97_bus.c
+++ b/sound/ac97_bus.c
@@ -19,9 +19,9 @@

 /*
  * Let drivers decide whether they want to support given codec from their
- * probe method.  Drivers have direct access to the struct snd_ac97 structure and may
- * decide based on the id field amongst other things.
- */
+ * probe method. Drivers have direct access to the struct snd_ac97
+ * structure and may  decide based on the id field amongst other things.
+*/
 static int ac97_bus_match(struct device *dev, struct device_driver *drv)
 {
        return 1;
$git format-patch master..jeffrin
0001-sound-Fixed-line-limit-issue-in-sound-ac97_bus.c.patch
$./scripts/checkpatch.pl 0001-sound-Fixed-line-limit-issue-in-sound-ac97_bus.c.patch
total: 0 errors, 0 warnings, 12 lines checked

0001-sound-Fixed-line-limit-issue-in-sound-ac97_bus.c.patch has no obvious style
problems and is ready for submission.
$

What is an Unevictable LRU Infrastructure ?

RELATED TO Unevictable

The Unevictable LRU infrastructure addresses the following classes of
unevictable pages:

+ page owned by ram disks or ramfs
+ page mapped into SHM_LOCKed shared memory regions
+ page mapped into VM_LOCKED [mlock()ed] vmas

Least  Recently Used  (LRU): discards  the least  recently  used items first. This  algorithm requires
keeping  track of what was  used when, which  is expensive if  one wants  to make  sure the  algorithm
always discards the least recently used item. General implementations of this technique require  to keep
"age bits" for  cache-lines and  track the "Least  Recently   Used"  cache-line   based  on  age-bits.
In  such implementation, every time a cache-line  is used, the age of all other cache-lines changes.  LRU
is actually  a family of  caching algorithms with members including:  2Q by Theodore Johnson and  Dennis
Shasha and LRU/K by Pat O'Neil, Betty O'Neil and Gerhard Weikum.


Hugetlb pages are also  unevictable. Hugepages are already implemented in a way  that these pages don't
reside on the LRU and  hence are not iterated over during  the vmscan.  So there is no  need to move
around these pages  across different  LRU's. We just  account these  pages as unevictable for correct
statistics.

The Unevictable LRU  adds an additional LRU list  to track unevictable pages and to hide these pages from
vmscan.  This mechanism is based on a patch  by Larry  Woodman of Red  Hat to address  several
scalability problems with page reclaim in  Linux.  The problems have been observed at  customer sites  on
large  memory x86_64  systems.  For  example, a non-numal x86_64 platform with 128GB  of main memory will
have over 32 million 4k  pages in a  single zone.  When  a large fraction  of these pages are not
evictable for  any reason [see below], vmscan will spend a lot of time scanning the LRU lists looking for
the small fraction of pages that  are evictable.  This can  result in a  situation where all cpus are 4
spending 100% of their time  in vmscan for hours  or days on end, with the system completely
unresponsive.

TYPICAL COMMANDLINE RELATED EXPOSURE
[bash]
$sudo cat /proc/meminfo | grep -A 5 -B 5 Unevictable
Inactive: 1591548 kB
Active(anon): 595404 kB
Inactive(anon): 502680 kB
Active(file): 1009628 kB
Inactive(file): 1088868 kB
Unevictable: 130612 kB
Mlocked: 80 kB
SwapTotal: 8075260 kB
SwapFree: 8074736 kB
Dirty: 260 kB
Writeback: 0 kB
$

[/bash]

LINKS
https://www.kernel.org/doc/Documentation/vm/unevictable-lru.txt
https://serverfault.com/questions/886483/how-to-determine-which-processes-have-unevictable-memory
https://stackoverflow.com/questions/4343249/unevictable-page
https://stackoverflow.com/questions/1072643/how-can-i-make-grep-print-the-lines-below-and-above-each-matching-line

Unevictable: 4 kB 0.1

Unevictable:           4 kB

The Unevictable LRU infrastructure addresses the following classes of
unevictable pages:

+ page owned by ram disks or ramfs
+ page mapped into SHM_LOCKed shared memory regions
+ page mapped into VM_LOCKED [mlock()ed] vmas

Least  Recently Used  (LRU): discards  the least  recently  used items
first. This  algorithm requires keeping  track of what was  used when,
which  is expensive if  one wants  to make  sure the  algorithm always
discards the least recently used item. General implementations of this
technique require  to keep  "age bits" for  cache-lines and  track the
"Least  Recently   Used"  cache-line   based  on  age-bits.   In  such
implementation, every time a cache-line  is used, the age of all other
cache-lines changes.  LRU is actually  a family of  caching algorithms
with members including:  2Q by Theodore Johnson and  Dennis Shasha and
LRU/K by Pat O'Neil, Betty O'Neil and Gerhard Weikum.



Hugetlb pages are also  unevictable. Hugepages are already implemented
in a way  that these pages don't  reside on the LRU and  hence are not
iterated over during  the vmscan.  So there is no  need to move around
these pages  across different  LRU's. We just  account these  pages as
unevictable for correct statistics.



The Unevictable LRU  adds an additional LRU list  to track unevictable
pages and to hide these pages from vmscan.  This mechanism is based on
a patch  by Larry  Woodman of Red  Hat to address  several scalability
problems with page reclaim in  Linux.  The problems have been observed
at  customer sites  on large  memory x86_64  systems.  For  example, a
non-numal x86_64 platform with 128GB  of main memory will have over 32
million 4k  pages in a  single zone.  When  a large fraction  of these
pages are not evictable for  any reason [see below], vmscan will spend
a lot of time scanning the LRU lists looking for the small fraction of
pages that  are evictable.  This can  result in a  situation where all
cpus are  spending 100% of their time  in vmscan for hours  or days on
end, with the system completely unresponsive.
Work Style
1. Get topic from the community.
2. Select easy or interested area from the topic.
3. Play with it.
4. Create screenshot.
5. Organize

logger—0.6.xml

[daemon.log]Every   daemon  without  a   separate  facility   logs  to
daemon.log.  The  priority of  log events is  not relevent.[debug]File
debug has messages useful for debugging.The priority of log events are
not relevent.[dmesg] After the  kernel has booted, all kernel messages
are written to dmesg for  later reference.This file is not rotated and
only exists for a single boot cycle before being overwritten.Note that
the choice of  the name is a little unfortunate,  as the dmesg command
prints  the  current  kernel  log ring  buffer,which  is  continuously
updated and new kernel events are logged.These messages are written to
kern.log; The dmesg file is not modified until the next restart of the
system.[kern.log] Log messages  with the kern facility end  up in this
file.The  contents are mostly  what the  kernel spits  out,after being
formatted by klogd.[lpr.log]Log messages  with the lpr facility end up
in this file.


[mail.log]  Log entries  related  to the  mail  system(using the  mail
facility) go into  this file.  For easier parsing  by scripts,mail log
entries    are    also    written    to    mail.info,    mail.warn,and
mail.err,according to  their priority.  Unfortunately,Debian's default
MTA,exim4,  does not  use this  file.[messages]Pretty  much everything
that  is not  an  error or  a  trivial log  entry,and  not related  to
authentication,daemons  ,cron(or other  automatic schedulers),mail,and
news goes here.

btmp auth.log syslog boot 

btmp shows a log of the file /var/log/btmp, which contains all the bad
login   attempts.    auth.log   receives   log  entries   related   to
authentication,and  other  events  that  are critical  to  privacy  or
security issues.   everything not related to authentication  end up in
syslog file.   syslog is  the catch-all log  file on a  debian system.
log  messages  produced during  the  initialization  sequence will  be
logged to boot.

[youtube=http://www.youtube.com/watch?v=WCHUb-n6hfw&fs=1&hl=en_US&rel=0]