プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

top(1)のSWAPフィールドは何を表示しているか このエントリーをはてなブックマークに追加

top(1)でSWAP量を表示出来るんだけど、「あれー、カーネルにそんな機能なかったよなー」と不思議に思い実装を調べてみたら、

total_vm(= 仮想アドレス空間のサイズ) - rss

というトンデモ計算式を使っていた。複数のプロセスで今日されてるページと、デマンドページングを無視している時点で近似値にすらなっていない。
実装したら、テストしようよ。公開する前に。


関連記事
スポンサーサイト
linux | 【2009-10-31(Sat) 01:07:55】 | Trackback:(0) | Comments:(3)

OOM Killer論争 Again このエントリーをはてなブックマークに追加

LKMLで、OOM Killが起きると誰が悪くても、絶対Xが死ぬ。という主張をする人が出現。最初は「んな、ばかな」と思っていたが、やってみるとたしかに死ぬ。
原因は、現在のOOM ScoreがVSZ ベースで計算していて、イマドキのGnomeアプリはライブラリを死ぬほどリンクするので、gnome-sessionがちょっとやそっとのfork-bombでは太刀打ち出来ないぐらい高い(死にやすい)OOM Scoreを持っている。

うーん、これは要修正だな。

関連記事
linux | 【2009-10-27(Tue) 15:49:25】 | Trackback:(0) | Comments:(2)

2009年度日本OSS貢献者賞とかいうものに選ばれたようです このエントリーをはてなブックマークに追加


http://itpro.nikkeibp.co.jp/article/NEWS/20091023/339364/
http://www.ipa.go.jp/about/press/pdf/091023Press.pdf (PDF)

へー( ゚д゚)
受賞理由をみると同姓同名の別人のような気がしなくもない

関連記事
雑談 | 【2009-10-23(Fri) 21:27:45】 | Trackback:(0) | Comments:(17)

Autotest というコミュニティがあるらしい このエントリーをはてなブックマークに追加

IPAのLinux互換性検証のプレスリリースhttp://www.ipa.go.jp/about/press/20091014.html で知ったAutotest というコミュニティ&ツール http://autotest.kernel.org/


http://test.kernel.org/linux_symposium_2009.pdf

ざっと見た感じだと

・ジョブスクリプトを書いておくと、複数のテストマシンにテストを振り分けて自動実行してくれる
・テストサーバとテストクライアントが別マシンなのを生かし、テストでカーネルクラッシュが発生してもテストサーバはクラッシュを自動検知 fail +1 としてテストを継続してくれる。

というのがウリのよう。開発主体はGoogle。
これは、勉強する価値があるかもしれない。


関連記事
linux | 【2009-10-16(Fri) 00:13:57】 | Trackback:(0) | Comments:(1)

IPA、Linuxカーネルの互換性情報を提供 このエントリーをはてなブックマークに追加

とかいう、ニュースが出てた。ソースはこれ。

http://www.atmarkit.co.jp/news/200910/15/ipa.html

せっかくなので、CrackerJackのサイトを見てみた。

ここで、面白い事を発見。
sched_yeildのテストケースが、今までスケジューラがfork時にchildを優先動作させるのを仮定しているので、今回のカーネルウォッチで取り上げたスケジューラの変更(fork時にparentが継続するようになった)により、非互換検出されてしまっている。
うーん、これはテストケースのバグだよなー

http://ossipedia.ipa.go.jp/crackerjack/cjk/system_calls/187.html
http://ossipedia.ipa.go.jp/crackerjack/cjk/compare_logs/100450.html

関連記事
linux | 【2009-10-15(Thu) 23:56:41】 | Trackback:(0) | Comments:(0)

kernel watch 9月版 このエントリーをはてなブックマークに追加

公開されました。

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


前号の次回予告をあっさり裏切って、スケジューラ特集。だって、編集部から指示されたんだもん。
おかげで、僕はシルバーウィークが潰れました。編集さんは今まで校正に苦しむハメになりました。
(一応僕は先月のうちに作業終わってたんじゃよー。サボってたんじゃないよ)

ここだけの話、指定文字数的には軽く2倍を超えてます。だって、CFSってドキュメントが少ないから変更点だけ解説しても意味不明になってしまうんだもの。

次こそは。次こそは薄い内容で、編集さんに楽をさせます。ほんとです。ほんと。


関連記事
linux | 【2009-10-15(Thu) 00:55:56】 | Trackback:(0) | Comments:(6)

首藤研クラウドプロジェクト合宿に乱入してみた このエントリーをはてなブックマークに追加

あれ、なんか記事が消えてる。
というわけで再掲

週末に、首藤研クラウドプロジェクトが沼津で合宿をしているのを発見。まったく面識ないにも関わらず強引に乱入してきました。
首藤クラウドを作っているとか。すごいですね

証拠
http://www.shudo.net/diary/2009oct.html#20091010の中の
この写真http://www.shudo.net/diary/data/20091010/s-img_0504.jpg


そういう無法者っぷりにも関わらず、みなさま大変暖かく出迎えてくださり、楽しい週末ハックをすごせました。本当にありがとうございました。

実は一人だけ、こっそりLKMLハックをしたり内職まみれだったのはヒミツだだだ


関連記事
雑談 | 【2009-10-13(Tue) 15:24:50】 | Trackback:(0) | Comments:(1)

Kernel Summit参加者最終リスト このエントリーをはてなブックマークに追加

なんだ、山幡さんもいるじゃん。セプキャン反省会が出来るな(違
Satoさんは、かなり無茶な方向に誤記されていて若干可哀想である。



----------------------- Original Message -----------------------
From: "Theodore Ts'o"
To: ksummit-2009-discuss@lists.linux-foundation.org,
ksummit-2009-pc@lists.linux-foundation.org
Date: Thu, 08 Oct 2009 15:54:57 -0400
Subject: [Ksummit-2009-discuss] Kernel summit attendee list
----


This is the final Kernel Summit attendee list. This includes those
invited to speak on the enterprise and embedded user panels, as well as
the sponsored attendees.

- Ted

Al Viro
Alan Cox
Andi Kleen
Andrew Morton
Andy Whitcroft
Arjan van de Ven
Arnd Bergmann
Avi Kivity
Benjamin Herrenschmidt
Brian Pawlowski
Chris Mason
Chris Schlaeger
Christoph Hellwig
Christoph Lameter
Chuck Lever
Dave Airlie
Dave Jones
David Howells
David S. Miller
David Woodhouse
Dirk Hohndel
Fernando Luis Vázquez Cao
Grant Likely
Greg Kroah-Hartman
H. Peter Anvin
Haavard Skinnemoen
Herbert Xu
Hiroyuki KAMEZAWA
Hugh Dickins
Inaky Perez-Gonzalez
Isaku Yamahata
James Bottomley
James Morris
Jan Kara
Jens Axboe
Jeremy Fitzhardinge
Jesse Barnes
Jiri Kosina
Johannes Berg
John W. Linville
Jonathon Corbet
Junichi Nomura
Kay Sievers
Kazuhiro Itakura
Keith Packard
Kentaro Takeda
Kosaki Motohiro
Kyle McMartin
Len Brown
Linus Torvalds
Luis R. Rodriguez
Martin Bligh
Martin Schwidefsky
Masanari Iida
Matthew Garrett
Matthew Wilcox
Mauro Carvalho Chehab
Mike Waychison
Miklos Szeredi
Munehiro Ikeda
Nick Piggin
Noburu Obata
Norihiro Kumagai
Norihisa Nakai
Paul Mackerras
Paul Mundt
Pekka Enberg
Peter Zijlstra
Petko Manolov
Rafael J. Wysocki
Ralf Baechle
Roland Dreier
Ryoichi Sugimura
Stephen Hemminger
Stephen Rothwell
Suresh Siddha
Takahiro Itagaki
Takashi Iwai
Tejun Heo
Theodore Ts'o
Thomas Gleixner
Tim Bird
Tomonori FUJITA
Tony Luck
Trond Myklebust
Venkatesh Pallipadi
Yoshinoro Sato
_______________________________________________
Ksummit-2009-discuss mailing list
Ksummit-2009-discuss@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/ksummit-2009-discuss



関連記事
linux | 【2009-10-09(Fri) 09:44:55】 | Trackback:(0) | Comments:(1)

驚きの真相! android ドライバがdropされたのは経産省の陰謀だった!! このエントリーをはてなブックマークに追加

という、アオリ記事をネタとして考えてみたがどうだろう。
ほら、一応直接の原因になったパッチは僕がセプキャン2009の最中にホテルから投げたパッチなので、あのイベントがなければ、今回のdropはなかったわけだし。

ここで、むりやり、国産技術にこだわる小役人とかをデッチ上げて、陰謀説にもっていくですよー


うん、無理があるな。


まあ、僕をセプキャンに誘った面々もまさかandroidが巻き添え食らって大被害をうけるとは予想しなかったであろう。わっはっは。
というわけで(どういうわけ?)、うらむならよしおかさんあたりを恨むですよー


関連記事
雑談 | 【2009-10-09(Fri) 08:43:04】 | Trackback:(0) | Comments:(4)

shrink_all_memoryは速くない このエントリーをはてなブックマークに追加

Linuxではハイバネート時のメモリ解放は普通のreclaimとは異なり、shrink_all_memory()という関数を通る。
色々とテストしていて、これが全然速くないことが分かった。

さて、どうやってrevertすべきか。revertパッチは作者のプライドを傷つけるので感情論になりがちという問題がやっかい。



関連記事
linux | 【2009-10-08(Thu) 22:53:46】 | Trackback:(0) | Comments:(0)

Gentooすげーー このエントリーをはてなブックマークに追加

http://www.nikkeibp.co.jp/it/article/NEWS/20091007/338507/

 Gentoo Linux 10.0 Live DVDでは、主に各アプリケーションのバージョンアップが行われている。例えば、カーネル 3.6.30、glibc 2.9、gcc 4.3.2が採用されている。デスクトップ環境では、KDE 4.3.1(写真1)、GNOME 2.26.3、Xfce 4.6.1などが選択できる。さらに、OpenOffice.org 3.1.1、Firefox 3.5.3、GIMP 2.6.4、MPlayer 1.0 rc4などが利用可能だ。



いや、すごいのは日経BPか?
とにかく奴らは未来を生きているよ



未来を生きている




関連記事
linux | 【2009-10-07(Wed) 22:55:32】 | Trackback:(0) | Comments:(3)

Windows7 のレビュー(ただし、対象はeBayで買った海賊版) このエントリーをはてなブックマークに追加

http://cpplover.blogspot.com/2009/10/crackedcomreview-of-windows-7.html

なにこれ。面白すぎる


関連記事
雑談 | 【2009-10-07(Wed) 22:07:42】 | Trackback:(0) | Comments:(1)

さようならandroid? このエントリーをはてなブックマークに追加

なんか、DreamCastの巻き添えを食らってandroidのコードが全削除食らったようだ。
何この面白展開

On Mon, Oct 05, 2009 at 04:21:35PM -0700, Randy Dunlap wrote:
> On Mon, 5 Oct 2009 19:03:24 +1100 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Changes since 20091002:
>
>
> drivers/staging/dream/gpio_axis.c:18:30: error: linux/gpio_event.h: No such file or directory

Argh, I'm getting sick of the dream code. I'll sit down tomorrow and
work it all out, _or_ just delete the tree.

I just deleted drivers/staging/android/ so getting dream support seems a
bit far off :(


DreamCastの開発を今更やっているのも、その巻き沿いでAndroidがアボーンされるのもネタとして面白すぎる

追記:typoを修正。DreadCastになってた

追記2: Paulからツッコミ。dreamディレクトリは欧米向けの携帯電話らしい。失礼。

追記3: このdropの直接的な原因は、長期のビルドエラー放置なんだけど、ビルドエラーの直接の原因は僕がDavidのOOMパッチをRevertしたときのrevert漏れだった。ははは、android関係者すまん。もし、もう一度mainlineを狙うなら協力せんでもないっすよ。

追記4: なんか、一部で誤解を招いているようなのでさらに補足。というか自己弁護。僕は一ヶ月以上前に修正パッチを投稿しているので、無視し続けた android 関係者が一番悪いんです。


関連記事
linux | 【2009-10-06(Tue) 15:48:16】 | Trackback:(0) | Comments:(4)

ext4はReiser3より遅い このエントリーをはてなブックマークに追加

定期的に現れるext4は遅いスレッド。今回はReiser3から移行したらカーネルコンパイルが
遅くなったというもの

Hello,

I'm considering replacing Reiser3 filesystem with some newer one.
I ran compilebench benchmark. Read performance is lower with ext4.
Is it expected or is it possible to fix it?

Ext4:
read tree total runs 11 avg 20.47 MB/s (user 0.53s sys 0.74s)
read compiled tree total runs 4 avg 32.94 MB/s (user 0.61s sys 1.17s)

Reiser3:
read tree total runs 11 avg 26.33 MB/s (user 0.54s sys 0.81s)
read compiled tree total runs 4 avg 41.82 MB/s (user 0.62s sys 1.36s)

RAID details:

md8 : active raid10 sda7[0] sdd7[3] sdc7[2] sdb7[1]
62925824 blocks 256K chunks 2 far-copies [4/4] [UUUU]

Ext4:
mkfs.ext4 -E stride=64,stripe-width=128 /dev/md8
mount -t ext4 -o noatime,auto_da_alloc,commit=600 /dev/md8 /mnt/md8

Reiser3:
mount -t reiserfs /dev/md8 /mnt/md8
mount -t reiserfs -o noatime,notail /dev/md8 /dev/md8

Ext4 results:
intial create total runs 10 avg 172.76 MB/s (user 0.43s sys 0.60s)
create total runs 14 avg 36.49 MB/s (user 0.42s sys 0.59s)
patch total runs 15 avg 15.16 MB/s (user 0.24s sys 0.49s)
compile total runs 14 avg 64.07 MB/s (user 0.10s sys 0.59s)
clean total runs 10 avg 393.43 MB/s (user 0.02s sys 0.06s)
read tree total runs 11 avg 20.47 MB/s (user 0.53s sys 0.74s)
read compiled tree total runs 4 avg 32.94 MB/s (user 0.61s sys 1.17s)
delete tree total runs 10 avg 2.51 seconds (user 0.24s sys 0.42s)
delete compiled tree total runs 4 avg 2.63 seconds (user 0.28s sys 0.50s)
stat tree total runs 11 avg 1.99 seconds (user 0.23s sys 0.18s)
stat compiled tree total runs 7 avg 2.11 seconds (user 0.27s sys 0.21s)

Reiser3 results:
intial create total runs 10 avg 82.74 MB/s (user 0.45s sys 1.13s)
create total runs 14 avg 28.54 MB/s (user 0.45s sys 1.19s)
patch total runs 15 avg 10.91 MB/s (user 0.24s sys 0.86s)
compile total runs 14 avg 47.49 MB/s (user 0.10s sys 1.27s)
clean total runs 10 avg 270.21 MB/s (user 0.02s sys 0.15s)
read tree total runs 11 avg 26.33 MB/s (user 0.54s sys 0.81s)
read compiled tree total runs 4 avg 41.82 MB/s (user 0.62s sys 1.36s)
delete tree total runs 10 avg 3.38 seconds (user 0.24s sys 0.72s)
delete compiled tree total runs 4 avg 4.14 seconds (user 0.27s sys 0.88s)
stat tree total runs 11 avg 2.09 seconds (user 0.22s sys 0.18s)
stat compiled tree total runs 7 avg 2.27 seconds (user 0.25s sys 0.21s)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



creating tar of compiled kernel takes much longer with ext4

time tar c linux-2.6.31 | cat >/dev/null

reiser3:
real 0m11.425s
user 0m0.229s
sys 0m1.586s

ext4:
real 0m23.942s
user 0m0.183s
sys 0m1.440s

partition was remounted before test


これに対するTedの回答。
dir_indexをOFFにしたら速くなると思うよ。ext4の改善はない。


You didn't say which version of the kernel you are using, which could
be important when asking these sorts of questions about potential
performance problems.

However, in this case, I suspect the issue is the nature of how
compilebench is structured. Compilebench does the following which
makes it work particularly well for filesystems like reiserfs and
btrfs, and not so much for ext3 and ext4. Quoting from the
compilebench web page:

compilebench starts by putting these lists of file names into an
order native to the filesystem it is working on. The files are
created in sorted order based on the filename, and then readdir is
used to find the order the filesystem uses for storing the
names. After this initial phase, the filesystem native order is
used for creates, patches and compile. Deleting, reading and
stating the trees are done in readdir order.

The key here is that it reads the tree in readdir order. Normally,
when you compile a kernel, the order in which you read and write files
is controlled by the Makefile; you don't get to read and write the
files in the order which just happens to be the most convenient for
the file system's b-tree hash algorithm.

Now, there are some workloads which compilebench might accurately
model --- for example, tar'ing up a directory. However, despite the
name of the benchmark, it doesn't accurately model a kernel compile.

If you only care about compilebench numbers, you can try creating the
file system with the dir_index feature disabled. This is the feature
that speeds up random access to directories; unfortunately, it means
that when you read files in readdir order, it causes extra random
reads to th einode table. However, if your real-life workload is one
where file reads are always magically in readdir order, dir_index adds
overhead without adding any benefit.

The bottom line is that I'm not terribly worried about trying to
improve ext4's performance on compilebench, since I don't believe it's
a benchmark that models realistic real-life workloads.

Regards,

- Ted



関連記事
linux | 【2009-10-06(Tue) 13:46:36】 | Trackback:(0) | Comments:(0)

[kernel watch没ネタ集] さよならVMI このエントリーをはてなブックマークに追加

VMwareの連中が、伝統的なVMIを使ったパラバーチャライゼーションより、EPT/NPTを使ったほうが速いのが分かったので、VMIは近々削除するよ。とのこと

おいおい、つい最近までVMwareのコード書き換え技術はァァァァァァ、世界イチィィィィィィ
URYYYYYYYYYYYYYY

とかいってたじゃんか。


Hi,

We ran a few experiments to compare performance of VMware's
paravirtualization technique (VMI) and hardware MMU technologies (HWMMU)
on VMware's hypervisor.

To give some background, VMI is VMware's paravirtualization
specification which tries to optimize CPU and MMU operations of the
guest operating system. For more information take a look at this
http://www.vmware.com/interfaces/paravirtualization.html

In most of the benchmarks, EPT/NPT (hwmmu) technologies are at par or
provide better performance compared to VMI.
The experiments included comparing performance across various micro and
real world like benchmarks.

Host configuration used for testing.
* Dell PowerEdge 2970
* 2 x quad-core AMD Opteron 2384 2.7GHz (Shanghai C2), RVI capable.
* 8 GB (4 x 2GB) memory, NUMA enabled
* 2 x 300GB RAID 0 storage
* 2 x embedded 1Gb NICs (Braodcom NetXtreme II BCM5708 1000Base-T)
* Running developement build of ESX.

The guest VM was a SLES 10 SP2 based VM for both the VMI and non-VMI
case. kernel version: 2.6.16.60-0.37_f594963d-vmipae.

Below is a short summary of performance results between HWMMU and VMI.
These results are averaged over 9 runs. The memory was sized at 512MB
per VCPU in all experiments.
For the ratio results comparing hwmmu technologies to vmi, higher than 1
means hwmmu is better than vmi.

compile workloads - 4-way : 1.02, i.e. about 2% better.
compile workloads - 8-way : 1.14, i,e. 14% better.
oracle swingbench - 4-way (small pages) : 1.34, i.e. 34% better.
oracle swingbench - 4-way (large pages) : 1.03, i.e. 3% better.
specjbb (large pages) : 0.99, i.e. 1% degradation.

Please note that specjbb is the worst case benchmark for hwmmu, due to
the higher TLB miss latency, so it's a good result that the worst case
benchmark has a degradation of only 1%.

VMware expects that these hardware virtualization features will be
ubiquitous by 2011.

Apart from the performance benefit, VMI was important for Linux on
VMware's platform, from timekeeping point of view, but with the tickless
kernels and TSC improvements that were done for the mainline tree, we
think VMI has outlived those requirements too.

In light of these results and availability of such hardware, we have
decided to stop supporting VMI in our future products.

Given this new development, I wanted to discuss how should we go about
retiring the VMI code from mainline Linux, i.e. the vmi_32.c and
vmiclock_32.c bits.

One of the options that I am contemplating is to drop the code from the
tip tree in this release cycle, and given that this should be a low risk
change we can remove it from Linus's tree later in the merge cycle.

Let me know your views on this or if you think we should do this some
other way.

Thanks,
Alok


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



関連記事
linux | 【2009-10-06(Tue) 11:26:08】 | Trackback:(0) | Comments:(6)

[kernel watch没ネタ集] kill markers このエントリーをはてなブックマークに追加

最後のユーザがいなくなったとの理由で、markerが削除されました。
しかし、out of treeにSystemTapというビッグユーザーがいるんだが。。。

まあ、Christoph Hellwig や Ingo MolnarにSystemTapの事を話しても無駄である。
コミュニティ活動をしないFrankが悪い

関連記事
linux | 【2009-10-06(Tue) 11:16:09】 | Trackback:(0) | Comments:(0)

[kernel watch没ネタ集] staging から落ちそうなパッチ このエントリーをはてなブックマークに追加

Gregがしばらく前に2.6.32でのstagingの状況を報告してた。
これによると、かなり多くのドライバが作業が止まっているらしい。

android はいまだに2.6.29で作業してる。とかMicrosoftのHyper-V担当者が消えちゃったとか
面白い事が色々書いてある

まあ、ドライバ以外全部dropしてほしいね。正直

Hi all,

Here's a summary of the state of the drivers/staging/ tree, basically
what will be coming in the 2.6.32 merge, and what the status of the
different drivers are so far.

First off, drivers/staging/ is NOT a dumping ground for dead code. If
no one steps up to maintain and work to get the code merged into the
main portion of the kernel, the drivers will be removed.

As proof of that, the EPL (Ethernet Power Link) driver will be removed
in the .32 kernel, as no one is working on it, the upstream developers
never respond to my emails, and no one seems to care about it.

The pata_rdc driver is also going to be removed, as there is a "better"
one being merged through the libata tree for this hardware.

So, taking the drivers in chunks, here's some that have had active
development on for the .32 release:
- rt* wireless drivers. Bart has done amazing work merging all
of these together into something much better than they
originally were. And even better, they still work! Great
job Bart!

- rtl* wireless drivers. Again, Bart has been doing great work
here.

- wlan-ng driver: a bit of work here, but this seems to be
dropping off, with the loss of a test platform for the driver.
Hopefully someone has a device around and can help out here.

- comedi drivers had only a bit of work done, lots more is
needed here, let's not loose the fact that this is getting
closer to a mergable shape.

- Android drivers have had a bit of work done, but upstream
seems to not care at all about what is going on here, as they
are working to forward port their code to the 2.6.29! kernel.
{sigh}. If this keeps up, the drivers will be dropped in the
2.6.32 kernel release.
Note, Pavel has been adding some of the Dream hardware
drivers, which are separate from the core Android drivers. I
have no objection to those, but they should work to get merged
to their "correct" places in the tree in another release or
so.

- w35und driver. It's slowly being worked on.

- echo driver. This one is now in good enough shape to merge
into the main kernel tree. I'll send out review patches soon
for this.

- eth131x driver. Alan Cox is working on fixing up the issues in
this driver. Hopefully it will get into mergable shape soon.

New drivers that will show up in the .32 kernel release:
- vt66* wireless drivers. These VIA drivers are being actively
worked on to get into a much better shape. Nice job.

- new rt3090, and rtl8192e wireless drivers have been added and
worked on cleaning up issues involved in them.

- Microsoft Hyper-V drivers. Over 200 patches make up the
massive cleanup effort needed to just get this code into a
semi-sane kernel coding style (someone owes me a bit bottle of
rum for that work!) Unfortunately the Microsoft developers
seem to have disappeared, and no one is answering my emails.
If they do not show back up to claim this driver soon, it will
be removed in the 2.6.33 release. So sad...

- quatech_usb2 driver. I don't know if it quite works, but
someone is developing it, so I'm not complaining :)

- VME bus drivers. Yeah! They are progressing nicely.

- SEP and RAR drivers. Alan Cox has been working on cleaning
these up a lot.

- IIO (Industrial I/O), these are new drivers that are being
actively worked on.

- pohmelfs and dst. It seems that DST is dead, so I think I
will remove it in .33. pohmelfs is under active development
outside of the tree, and hopefully patches start moving in
here to help out with keeping it up to date.

- cowloop. Yes, another COW driver! :) Seriously, this does
things that DM can't do, so it might be useful. The upstream
developer is interested in getting this merged properly, and
is working on cleaning it up.

Drivers not being actively worked on:
- otus. This is sitting here until a "real" wireless driver
will be merged through the wireless tree. Hopefully that
happens soon.

- agnx wireless driver. No one seems to care about it. If no
one steps up soon, it will be removed in .33.

- altpciechdma. Upstream developers seem to have disappeared.
Again, if no one steps up, it will be removed in .33

- asus_oled. This only needs minor cleanups to get merged
properly into the main tree. If someone wants an easy
project, this would be it.

- at76_usb wireless driver. Again, no one working on it, it
will be dropped in .33.

- b3dfg. I really do not think anyone cares about this. again,
will be dropped if this is true in .33.

- cpc-usb. After the initial flurry of development, everyone
seems to have run away. Was it the fact that I hadn't
showered in a few days? Again, will be removed if no one
comes back. And I am wearing deodorant now...

- frontier. A nice driver, again, should not be hard to get
merged into the main tree, if someone wants an easy project...

- go7007. Ugh. Unless someone steps up now to take this over,
it's going to be removed in .33. There is no hardware made
with this anymore, and no specs around that I know of, and the
code isn't the nicest in the world.

- heci. A wonderful example of a company throwing code over the
wall, watching it get rejected, and then running away as fast
as possible, all the while yelling over their shoulder, "it's
required on all new systems, you will love it!" We don't, it
sucks, either fix it up, or I am removing it.

- line6. Another nice driver that should be simple to get
merged. Please, if you are looking for something to do, this
is it.

- me4000 and meilhaus. They work on the same hardware, and they
duplicate the existing COMEDI drivers. Someone thinks that
custom userspace interfaces are fun and required. Turns out
that being special and unique is not what to do here, use the
COMEDI drivers instead. These will be removed. Heck, I'll go
remove them for .32, there is no reason these should still be
around, except to watch the RT guys squirm as they try to
figure out the byzantine locking and build logic here (which
certainly does count for something, cheap entertainment is
always good.)

- mimio. Another driver that should be simple to get merged.
Someone just step up to do this please, there are users of
this hardware out there.

- p9auth. While it seemed like a good idea, I don't think that
anyone actually uses this. It will be removed in .33 unless
someone comes forward.

- panel. Another one that should be simple to merge. Anyone?

- phison. What? I thought I asked for this to be merged a
while ago, sorry about that, no reason it should still be in
staging anymore, it's just so small it slipped through the
cracks...

- poch. A long-suffering company is enduring the slowest
developers in the world here. Hopefully the code will be
replaced with a UIO driver, but testing the userspace side
seems to be difficult and slow. I have to give Redrapids
major credit for being patient here, they are being amazing.

- rspiusb. A weird, very expensive camera, from a company that
does not want to release the specs, and wants custom userspace
interfaces. The code hasn't built since the 2.6.20 days.
I'll go delete it now from .32, it doesn't deserve to live as
no one cares about it, least of all, the original authors of
the code :(

- slicoss and sxg. These are being developed by a consulting
company for the main producer of the chips. Yet they seem to
have disappeared half-way through the job. Odd. Hopefully
they come back soon.

- stlc45xx. Another wireless driver that no one seems to care
about. So sad. I guess no one will miss it when it goes away
in .33.

- udlfb. Video over USB, it doesn't get anymore whacked than
that. This is still being developed but the developer doesn't
like to do incremental updates for some odd reason. Hopefully
he pops up again with an update. But for now, it is quite
workable for a number of developers.

- usbip. USB over IP. I guess if you ran video over IP to your
USB device, that would be more whacked than just video over
USB. This did get one big update during the .32 development
cycle, hopefully the developer can come back again when they
get some free time to continue working on it. Rumor has it
that some major distros are starting to rely on this code, so
it would be nice to get their help to get it working better...

That should cover all of the 600+ patches in the staging tree for the
.32 kernel merge, and the existing drivers/staging/ tree. If I missed
anything, please let me know.

Any questions?

thanks for making it this far,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


関連記事
linux | 【2009-10-06(Tue) 11:13:55】 | Trackback:(0) | Comments:(0)

Userspace RCU library このエントリーをはてなブックマークに追加

http://lttng.org/?q=node/18

また奇特な

関連記事
linux | 【2009-10-05(Mon) 12:21:46】 | Trackback:(0) | Comments:(0)

住宅販売 このエントリーをはてなブックマークに追加

なんか、住宅販売のチラシが家に投げ込まれてた、見るともなく見ていると、・・ええ!4千万!!
誰が買うんだ、こんなの?

50坪、駅3分の価値を思い知った。

関連記事
雑談 | 【2009-10-04(Sun) 23:07:57】 | Trackback:(0) | Comments:(0)

ext4 さん弱すぎる このエントリーをはてなブックマークに追加

今日普通に再起動したら、起動時に以下のエラーが。
panicもしてないのに、ファイルシステムを壊さないでいただきたい O( `д´*)o


EXT4-fs error (device dm-0): ext4_mb_generate_buddy: EXT4-fs: group 120: 17771 blocks in bitmap, 18273 in gd
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825636(bit 23396 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825637(bit 23397 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825638(bit 23398 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825639(bit 23399 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825640(bit 23400 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825641(bit 23401 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825642(bit 23402 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825643(bit 23403 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825644(bit 23404 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825592(bit 23352 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825593(bit 23353 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825594(bit 23354 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825595(bit 23355 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825596(bit 23356 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825597(bit 23357 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825609(bit 23369 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825610(bit 23370 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825611(bit 23371 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825612(bit 23372 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks:
EXT4-fs error (device dm-0): mb_free_blocks:
EXT4-fs error (device dm-0): mb_free_blocks:
EXT4-fs error (device dm-0): mb_free_blocks:
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825625(bit 23385 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 3935628(bit 3468 in group 120)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 3935629(bit 3469 in group 120)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 3935630(bit 3470 in group 120)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 3935631(bit 3471 in group 120)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 3935632(bit 3472 in group 120)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 3935633(bit 3473 in group 120)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 3935634(bit 3474 in group 120)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 3935635(bit 3475 in group 120)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 3935636(bit 3476 in group 120)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825571(bit 23331 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825572(bit 23332 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825573(bit 23333 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825574(bit 23334 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825575(bit 23335 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825576(bit 23336 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825577(bit 23337 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825578(bit 23338 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825579(bit 23339 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825541(bit 23301 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825542(bit 23302 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825543(bit 23303 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825544(bit 23304 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825545(bit 23305 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825556(bit 23316 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825557(bit 23317 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825558(bit 23318 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825559(bit 23319 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825560(bit 23320 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825380(bit 23140 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825381(bit 23141 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825382(bit 23142 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825383(bit 23143 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825384(bit 23144 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825365(bit 23125 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825366(bit 23126 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825367(bit 23127 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825368(bit 23128 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825369(bit 23129 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825338(bit 23098 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825339(bit 23099 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825340(bit 23100 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825341(bit 23101 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825342(bit 23102 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825343(bit 23103 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825344(bit 23104 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825345(bit 23105 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825346(bit 23106 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825347(bit 23107 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825348(bit 23108 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825324(bit 23084 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825325(bit 23085 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825326(bit 23086 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825327(bit 23087 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825328(bit 23088 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825309(bit 23069 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825310(bit 23070 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825311(bit 23071 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825312(bit 23072 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825313(bit 23073 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825293(bit 23053 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825294(bit 23054 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825295(bit 23055 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825296(bit 23056 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825297(bit 23057 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825298(bit 23058 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825657(bit 23417 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825658(bit 23418 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825659(bit 23419 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825660(bit 23420 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825661(bit 23421 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks:
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825672(bit 23432 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825673(bit 23433 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825674(bit 23434 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825675(bit 23435 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825676(bit 23436 in group 55)
EXT4-fs error (device dm-0): mb_free_blocks: double-free of inode 0's block 1825677(bit 23437 in group 55)



関連記事
linux | 【2009-10-04(Sun) 20:48:01】 | Trackback:(0) | Comments:(0)
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。