do { \
if (blah(x) < 0) \
return -EBUGGERED; \
- } while(0)
+ } while (0)
is a _very_ bad idea. It looks like a function call but exits the "calling"
function; don't break the internal parsers of those who will read the code.
!Iinclude/linux/input-polldev.h
!Edrivers/input/input-polldev.c
</sect1>
- <sect1><title>Matrix keyboars/keypads</title>
+ <sect1><title>Matrix keyboards/keypads</title>
!Iinclude/linux/input/matrix_keypad.h
</sect1>
<sect1><title>Sparse keymap support</title>
If you do not know where you want to start, but you want to look for
some task to start doing to join into the kernel development community,
go to the Linux Kernel Janitor's project:
- http://kernelnewbies.org/KernelJanitors
+ http://kernelnewbies.org/KernelJanitors
It is a great place to start. It describes a list of relatively simple
problems that need to be cleaned up and fixed within the Linux kernel
source tree. Working with the developers in charge of this project, you
release a new -rc kernel every week.
- Process continues until the kernel is considered "ready", the
process should last around 6 weeks.
- - Known regressions in each release are periodically posted to the
- linux-kernel mailing list. The goal is to reduce the length of
- that list to zero before declaring the kernel to be "ready," but, in
- the real world, a small number of regressions often remain at
- release time.
It is worth mentioning what Andrew Morton wrote on the linux-kernel
mailing list about kernel releases:
--------------------------------
It can be helpful to manually add In-Reply-To: headers to a patch
-(e.g., when using "git send email") to associate the patch with
+(e.g., when using "git send-email") to associate the patch with
previous relevant discussion, e.g. to link a bug fix to the email with
the bug report. However, for a multi-patch series, it is generally
best to avoid using In-Reply-To: to link to older versions of the
# (If no arguments are given then it will print the host architecture's status.)
#
-ARCH=${1:-$(arch | sed 's/x86_64/x86/' | sed 's/i386/x86/')}
+ARCH=${1:-$(uname -m | sed 's/x86_64/x86/' | sed 's/i386/x86/')}
cd $(dirname $0)
echo "#"
Each registered i2c adapter gets a number, counting from 0. You can
examine /sys/class/i2c-dev/ to see what number corresponds to which adapter.
-Alternatively, you can run "i2cdetect -l" to obtain a formated list of all
+Alternatively, you can run "i2cdetect -l" to obtain a formatted list of all
i2c adapters present on your system at a given time. i2cdetect is part of
the i2c-tools package.
I2C bus. The memory contents can be modified from userspace via this file
located in sysfs:
- /sys/bus/i2c/devices/<device-direcory>/slave-eeprom
+ /sys/bus/i2c/devices/<device-directory>/slave-eeprom
As of 2015, Linux doesn't support poll on binary sysfs files, so there is no
-notfication when another master changed the content.
+notification when another master changed the content.
てこの状態を変えようとしないように。人々はそのようなことは好みません。
今までのメールでのやりとりとその間のあなたの発言はそのまま残し、
-"John Kernlehacker wrote ...:" の行をあなたのリプライの先頭行にして、
+"John Kernelhacker wrote ...:" の行をあなたのリプライの先頭行にして、
メールの先頭でなく、各引用行の間にあなたの言いたいことを追加するべきで
す。
INSTALLING the kernel source:
- If you install the full sources, put the kernel tarball in a
- directory where you have permissions (eg. your home directory) and
+ directory where you have permissions (e.g. your home directory) and
unpack it:
xz -cd linux-4.X.tar.xz | tar xvf -
When compiling the kernel, all output files will per default be
stored together with the kernel source code.
- Using the option "make O=output/dir" allow you to specify an alternate
+ Using the option "make O=output/dir" allows you to specify an alternate
place for the output files (including .config).
Example:
"make nconfig" Enhanced text based color menus.
- "make xconfig" X windows (Qt) based configuration tool.
+ "make xconfig" Qt based configuration tool.
- "make gconfig" X windows (GTK+) based configuration tool.
+ "make gconfig" GTK+ based configuration tool.
"make oldconfig" Default all questions based on the contents of
your existing ./.config file and asking about
Normally, the kernel build system runs in a fairly quiet mode (but not
totally silent). However, sometimes you or other kernel developers need
to see compile, link, or other commands exactly as they are executed.
- For this, use "verbose" build mode. This is done by inserting
- "V=1" in the "make" command. E.g.:
+ For this, use "verbose" build mode. This is done by passing
+ "V=1" to the "make" command, e.g.
make V=1 all
kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
/boot/bzImage. To use the new kernel, save a copy of the old image
and copy the new image over the old one. Then, you MUST RERUN LILO
- to update the loading map!! If you don't, you won't be able to boot
+ to update the loading map! If you don't, you won't be able to boot
the new kernel image.
Reinstalling LILO is usually a matter of running /sbin/lilo.
projects / karo-tx-linux.git / commitdiff