anticipatory I/O scheduler が消えてる

全然気づいてなかったが 2.6.33で anticipatory I/O scheduler が削除されている。思い切ったなぁ

関連記事

ruby の systemtap対応できた (2010/01/10)
anticipatory I/O scheduler が消えてる (2009/12/17)
８０文字制限はナンセンスだ！ (2009/12/17)

linux | 【2009-12-17(Thu) 15:08:23】 | Trackback:(0) | Comments:(0)

８０文字制限はナンセンスだ！

現在のコーディング規約の８０文字制限はナンセンスだから、やめようぜ
というcheckpatch.pl の文字数チェックを廃止するパッチが投稿された。
周りの反応もおおむね好意的。

まあ、うざいのは事実なんですが完全に廃止すると、間抜けなコーディングが増殖しそうな
気もする。なにかいい折衷案はないものか。

From: Mikulas Patocka 
Subject: [PATCH] Drop 80-character limit in checkpatch.pl

Drop 80-character limit in checkpatch.pl

Serious issues:
===============

(1) The code is hard to edit with common text editors
-----------------------------------------------------

For example, let's have this function
struct some_structure *some_function(struct susystem *s, struct s_buffer *b, 
				     unsigned some_number, unsigned some_flags,
				     unsigned long *extra_return_value)

Now, try to make this function static. Or try to add/remove/change some
argument. You end up manually realigning all the arguments. The same problem
happens when editing longer expressions.

This is the most annoying problem with imposed text alignment. If there were
no alignment, you just type "I static SPACE ESC" in vi and get it there
(similarly HOME static SPACE in notepad). If you have to maintain alignment,
the number of keystokes becomes much higher:

			(insert the keyword)
I static SPACE ESC
			(split the second argument)
f , l s ENTER
			(align the second argument)
TAB TAB TAB TAB TAB SPACE SPACE SPACE SPACE ESC
		(see if the third argument fits --- it doesn't, revert it)
J u
			(align the third argument)
j ^ XXXXXX i TAB TAB SPACE SPACE SPACE SPACE ESC
			(split the fourth argument --- it is aligned well)
f , l s ENTER ESC
			(align the fifth argument)
j ^ XXXXXX i TAB TAB SPACE SPACE SPACE SPACE ESC

There are shorter possible sequences using vi keystrokes but the person doing
the editing doesn't always find the optimal way quickly enough, so the actual
editing will look somehow like this.

For emacs, there is a script in CodingStyle to make it conform to the Linux
kernel coding style, but the script only changes tabbing, it does absolutely
nothing with respect to the line width --- with the script loaded, emacs still
doesn't realign the arguments if you add a "static" keyword there.

[ I'm wondering, which editor does the person who invented and supports this
line-wrapping actually use. I suppose none :-) --- it looks like that person
mostly reads the code and tries to make it look aesthetical. ]

(2) Grepping the code is unreliable
-----------------------------------

For example, you see a message "device: some error happened" in syslog.
Now, you grep the kernel with a command (grep -r "some error happened" .) to
find out where it came from. You miss it if the code is formatted like this:
				if (some_error_happened) {
					printk(KERN_ERR "%s: some error "
						"happened", dev->name);
				}
In this case, you usually narrow the search to "error happened" and "some error"
and eventually find it.
Now, the real problem comes, when there are two instance of "some error
happened" message, one is wrapped and the other is not. Here, grep misleads you
to the non-wrapped instance and you are never going to find out that there is
another place where this error could be reported.

Similar grepping problems also exist (less frequently) when grepping the code
--- i.e. Where is the function "bla" called with argument BLA_SOME_FLAG?).
Grep and regular expressions give unreliable results because of 80-line
wrapping.

Less serious issues:
====================

(3) Wrapping wastes space on wide-screen displays
-------------------------------------------------

Obvious. The screen area past column 80 is not used at all.

(4) Wrapping wastes space on small 80x25 display
------------------------------------------------

It is less obvious, but let's see how artifical 80-column wrapping wastes space
on a real 80-column display.

With wrapping: 4 lines:
				struc = some_function(s, buffer, variable +
					get_something(123), FLAG_ONE |
					FLAG_TWO | FLAG_THREE | FLAG_FOUR,
					&extra_ret);

Without wrapping (note that the editor/viewer wraps it automatically at
column 80): 2 lines:
				struc = some_function(sub, buffer, variable + ge
t_something(123), FLAG_ONE | FLAG_TWO | FLAG_THREE | FLAG_FOUR, &extra_ret);

(5) Wrapping makes long expressions harder to understand
--------------------------------------------------------

If I have a complex expression, I do not try to wrap it at predefined
80-column boundaries, but at logical boundaries within the expression to make
it more readable (the brain can't find matching parentheses fast, so we can
help it by aligning the code according to topmost terms in the expression).

Example:
				if (unlikely(call_some_function(s, value) != RET
_SUCCESS) ||
				    (var_1 == prev_var_1 && var_2 == prev_var_2)
 ||
				    flags & (FLAG_1 | FLAG_2) ||
				    some_other_condition) {
				}

Now, if we impose 80-column limit, we get this. One may argue that is looks
aesthetically better, but it is also less intelligible than the previous
version:
				if (unlikely(call_some_function(s, value) !=
				    RET_SUCCESS) || (var_1 == prev_var_1 &&
				    var_2 == prev_var_2) || flags & (FLAG_1 |
				    FLAG_2) || some_other_condition) {
				}

Counter-arguments:
==================

Some people say that 80-column wrapping is imposed so that kernel code is
readable and editable in 80-column text mode.
(for example http://lkml.indiana.edu/hypermail/linux/kernel/0807.2/0010.html)

I personally use 80-column text mode a lot of time, yet I find the artifical
wrapping annoying. The key point is that the editor and viewer wrap the text
automatically at column 80, so there is never any text invisible and there is
no need to wrap it manually.

vi, less, mcview, emacs, grep, pine (*), mutt --- all these will automatically
skip to the next line if some line is longer than terminal width.

(*) pine does this auto-wrapping only in viewer mode, but no one writes code in
pine anyway.

If you rely on this auto-wrapping, you get split words (such as call_some_functi
on()), but I find these split words less annoying than having to manually
realign lines with tabs and spaces each time I edit something.

---

If this 80-column wrapping was only taken as a guidance --- use it or not, as
you like --- there would be little problem with it, because this manual
realigning doesn't annoy anyone but the person who writes the code.

But some maintainers take output of the script checkpatch.pl dogmatically,
requiring that every new work must pass the script without a warning. This is
counterproductive --- if I write a driver and I will be doing most maintenance
work on it in the future, it is viable that the driver is formatted in such
a way that is best editable for me, not for anyone else. And as shown in example
(1), this 80-column requirement makes even simple changes much harder.

So: I am submitting this patch for the checkpatch.pl script.

Signed-off-by: Mikulas Patocka 

---
 scripts/checkpatch.pl |    9 ---------
 1 file changed, 9 deletions(-)

Index: linux-2.6.32-devel/scripts/checkpatch.pl
===================================================================
--- linux-2.6.32-devel.orig/scripts/checkpatch.pl	2009-12-07 19:57:31.000000000 +0100
+++ linux-2.6.32-devel/scripts/checkpatch.pl	2009-12-07 19:57:44.000000000 +0100
@@ -1374,15 +1374,6 @@ sub process {
 # check we are in a valid source file if not then ignore this hunk
 		next if ($realfile !~ /\.(h|c|s|S|pl|sh)$/);

-#80 column limit
-		if ($line =~ /^\+/ && $prevrawline !~ /\/\*\*/ &&
-		    $rawline !~ /^.\s*\*\s*\@$Ident\s/ &&
-		    $line !~ /^\+\s*printk\s*\(\s*(?:KERN_\S+\s*)?"[X\t]*"\s*(?:,|\)\s*;)\s*$/ &&
-		    $length > 80)
-		{
-			WARN("line over 80 characters\n" . $herecurr);
-		}
-
 # check for adding lines without a newline.
 		if ($line =~ /^\+/ && defined $lines[$linenr] && $lines[$linenr] =~ /^\\ No newline at end of file/) {
 			WARN("adding a line without newline at end of file\n" . $herecurr);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

関連記事

anticipatory I/O scheduler が消えてる (2009/12/17)
８０文字制限はナンセンスだ！ (2009/12/17)
今日のstable tree reviewすごいな (2009/12/11)

linux | 【2009-12-17(Thu) 13:28:05】 | Trackback:(0) | Comments:(0)

京都の歴史ハンパない

http://www.ms-06zaku.com/

最初、慈音弘国の読みが分かりませんでした。さすが弘法大師はん。ハンパねぇっす！！

関連記事

ねた | 【2009-12-13(Sun) 21:31:58】 | Trackback:(0) | Comments:(0)

今日のstable tree reviewすごいな

パッチが90個あって全部ext4の修正とか。いいかげん安定してくれよ

関連記事

linux | 【2009-12-11(Fri) 14:32:36】 | Trackback:(0) | Comments:(0)

C++0x ってhex numberなの？

Kaz Kylheku：もし2010年にC++0xが出たら C++0x7DA ってこと？
Mathias Gaunard：そのjokeはもう古いんだぜ (´・ω・`)

http://groups.google.com/group/comp.std.c++/browse_thread/thread/5aa7115a76eaeb33#

おまえは何を言っているんだ という感じで最高です

関連記事

プログラミング | 【2009-12-11(Fri) 13:31:18】 | Trackback:(0) | Comments:(0)

ext4 update in 2.6.33

あいかわらず、ゼロ割りがどうのとかNULLを踏むからどうのとか、怖いというか初歩的というか迷う修正が多数。
あと、discardがデフォルトでOFFになったのが大きな違いか（強制ONでOFFにする手段なしだったが、マウントオプションが必要になった）

関連記事

linux | 【2009-12-11(Fri) 09:07:23】 | Trackback:(0) | Comments:(0)

kernel watch 11月号

http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch11a.html

公開されたようです。編集部の中で対応優先度がすごい勢いで下がってる気がするので来月から本気出す。
でも、たぶん、正月に書くので公開は年明けだな

追記：誰も信じてくれないけど恒例のいいわけを書いておこう「僕が原稿書いてたころはまだ11月だったんじゃよー」

関連記事

linux | 【2009-12-10(Thu) 21:58:51】 | Trackback:(0) | Comments:(0)

DRBDがマージ

これも気づいてなかった。直接LKMLで交渉すると却下されるから、Jensを通したのね。

関連記事

linux | 【2009-12-10(Thu) 20:01:01】 | Trackback:(0) | Comments:(0)

CFQ group schedulerがマージ

さっき、ついったーで嘘をつぶやいてしまったのだが、CFQ group scheduler (cgroup I/O controller)がLinusツリーにマージされたようだ。ほんの2日前。見逃していたよ。
これは大きい、I/Oが分割できないなんてリソース管理として片手落ちだったものな

関連記事

linux | 【2009-12-10(Thu) 17:15:52】 | Trackback:(0) | Comments:(0)

reiserfs のBKL削除パッチがマージ

でもロック粒度が細かくなったわけではないので、SMPに向かないFSであることに変わりはない。
BKL削除活動もそろそろ終わりが見えてきた感じかな。

関連記事

linux | 【2009-12-10(Thu) 09:31:35】 | Trackback:(0) | Comments:(2)

[メモ] perf と ftraceは両立できる

つい最近までperf stat -e tracepointでtracepointの統計を採取したら、内部的にftraceをenableしてしまうので、すでに別の統計をftraceで取っていたら、良くないことが起きると思っていたのだが、ちゃんとtracepointから別々のHookが呼ばれてバッファが混ざらないように配慮してあった。

関連記事

linux | 【2009-12-09(Wed) 12:03:16】 | Trackback:(0) | Comments:(0)

sysctl cleanupがマージされた

Eric W. Biederman のsysctlシステムコールなんか誰も使ってないんだから、みんな/proc/sys を使えばいいんだパッチシリーズがマージ。
実はほんの少数ユーザが残っていることが分かったので
・sysctl.c からはsysctlシステムコール対応のコードを全削除
・sysctl_binary.c を新設し、sysctl()システムコールが呼ばれたらテーブルlookupして適切な文字列を引数に
sysctl.c のテキスト版sysctl処理を呼び出す
・個々のsysctlハンドラからはsysctl()システムコールインターフェースを削除。新規チューニングパラメタは
/proc経由で使うのが必須

という感じになっている。sysctlコマンドがsysctl()システムコールを使ってない時点でsysctl()の残存ユーザがいたことにビックリだよ。

関連記事

[メモ] perf と ftraceは両立できる (2009/12/09)
sysctl cleanupがマージされた (2009/12/09)
Pentiumのfdiv_bug検出コードがバグってる (2009/12/08)

linux | 【2009-12-09(Wed) 09:03:58】 | Trackback:(0) | Comments:(0)

Pentiumのfdiv_bug検出コードがバグってる

むしろ、そんなハードが現存していたことにビックリだよ！

From: ZB
Subject: 2.6 kernels wrongly declare "fdiv_bug: no"

/proc/cpuinfo fdiv_bug says "no" in 2.6.32 and other 2.6 kernels,
but 2.4 kernels say "yes" as does the Intel utility

2.4.37:
Intel Pentium with F0 0F bug - workaround enabled.
CPU: Intel Pentium 75 - 200 stepping 01
Hmm, FPU with FDIV bug.
Checking 'hlt' instruction... OK.

processor : 0
vendor_id : GenuineIntel
cpu family : 5
model : 2
model name : Pentium 75 - 200
stepping : 1
cpu MHz : 90.205
fdiv_bug : yes
hlt_bug : no
f00f_bug : yes
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8
bogomips : 179.81

2.6.32:
Intel Pentium with F0 0F bug - workaround enabled.
[blank line here]
CPU: Intel Pentium 75 - 200 stepping 01
Checking 'hlt' instruction... OK.

processor : 0
vendor_id : GenuineIntel
cpu family : 5
model : 2
model name : Pentium 75 - 200
stepping : 1
cpu MHz : 90.199
cache size : 0 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : yes
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8
bogomips : 180.91
clflush size : 32
cache_alignment : 32
address sizes : 32 bits physical, 32 bits virtual
power management:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

関連記事

sysctl cleanupがマージされた (2009/12/09)
Pentiumのfdiv_bug検出コードがバグってる (2009/12/08)
「カーネル開発者会議「Kernel Summit」が日本初上陸」だってさ (2009/12/02)

linux | 【2009-12-08(Tue) 11:10:47】 | Trackback:(0) | Comments:(4)

【これはすごい】簡単なWebサーチエンジンの作り方

http://d.hatena.ne.jp/kzhk/20091202/p2

イマドキはこんな講義を大学でやるんだねぇ。自分も受けたかったよ

関連記事

C++0x ってhex numberなの？ (2009/12/11)
【これはすごい】簡単なWebサーチエンジンの作り方 (2009/12/03)
Java の closeDescriptors() (2009/09/14)

プログラミング | 【2009-12-03(Thu) 02:51:02】 | Trackback:(0) | Comments:(1)

「カーネル開発者会議「Kernel Summit」が日本初上陸」だってさ

日経Linux11月号に書いたKernel SummitレポートがITproに転載されたようです。

http://itpro.nikkeibp.co.jp/article/COLUMN/20091120/340844/

関係者の皆様、おつかれさま＆ありがとうございました（ぺこり

関連記事

Pentiumのfdiv_bug検出コードがバグってる (2009/12/08)
「カーネル開発者会議「Kernel Summit」が日本初上陸」だってさ (2009/12/02)
[LKML名言集] ４つは許容できない！ (2009/11/25)

linux | 【2009-12-02(Wed) 10:53:33】 | Trackback:(0) | Comments:(0)

[英語] Your proposal looks very promissing to me.

Your proposal looks very promissing to me.

あなたの提案はすごく有望だと思うよ。
MLで相手を褒める時に使う。メモ

関連記事

MAD_HWPOISON (2010/06/22)
[英語] Your proposal looks very promissing to me. (2009/12/01)
[英語] jumping the gun (2009/11/08)

英語 | 【2009-12-01(Tue) 12:12:24】 | Trackback:(0) | Comments:(4)