tmem, cleancache, zprojectを推進していた Dan Magenheimer が Oracleを退社することに伴い、しばらく開発を離れるらしい。この雰囲気だと二度と戻ってこない可能性も高いよな。

まあ、それはいいんだが、こいつも捨て台詞に「魚をありがとう」って書いてるんだけど、そんなに面白いジョークかなあ

Hi Linux kernel folks and Xen folks --

Effective July 5, I will be resigning from Oracle and "retiring"
for a minimum of 12-18 months and probably/hopefully much longer.
Between now and July 5, I will be tying up loose ends related to
my patches but also using up accrued vacation days. If you have
a loose end you'd like to see tied, please let me know ASAP and
I will do my best.

After July 5, any email to me via first DOT last AT oracle DOT com
will go undelivered and may bounce. Please send email related to
my open source patches and contributions to Konrad Wilk and/or Bob Liu.
Personal email directed to me can be sent to first AT last DOT com.

Thanks much to everybody for the many educational opportunities,
the technical and political jousting, and the great times at
conferences and summits! I wish you all the best of luck!
Or to quote Douglas Adams: "So long and thanks for all the fish!"

Cheers,
Dan Magenheimer
The Transcendent Memory ("tmem") guy

Tmem-related historical webography:
http://lwn.net/Articles/454795/
http://lwn.net/Articles/475681/
http://lwn.net/Articles/545244/
https://oss.oracle.com/projects/tmem/
http://www.linux-kvm.org/wiki/images/d/d7/TmemNotVirt-Linuxcon2011-Final.pdf
http://lwn.net/Articles/465317/
http://lwn.net/Articles/340080/
http://lwn.net/Articles/386090/
http://www.xen.org/files/xensummit_oracle09/xensummit_transmemory.pdf
https://oss.oracle.com/projects/tmem/dist/documentation/presentations/TranscendentMemoryXenSummit2010.pdf
https://blogs.oracle.com/wim/entry/example_of_transcendent_memory_and
https://blogs.oracle.com/wim/entry/another_feature_hit_mainline_linux
https://blogs.oracle.com/wim/entry/from_the_research_department_ramster
http://streaming.oracle.com/ebn/podcasts/media/11663326_VM_Linux_042512.mp3
https://oss.oracle.com/projects/tmem/dist/documentation/papers/overcommit.pdf
http://static.usenix.org/event/wiov08/tech/full_papers/magenheimer/magenheimer_html/

stack overflowから

http://stackoverflow.com/questions/4156055/gcc-static-linking-only-some-libraries

いくつかのライブラリだけスタティックリンクして、それ以外はダイナミックリンクする方法は？みたいな話
-Bdynamicを使えという案とスタティックリンクしたいライブラリだけ .a 拡張子つきで指定すればいいじゃんという案が二強


gcc <objectfiles> -static -lstatic1 -lstatic2 -Wl,-Bdynamic -ldynamic1 -ldynamic2

gcc some_static_lib.a -lsome_dynamic_lib code.c

Rubyvisというgemでグラフが綺麗に出力できるらしい。あとでみる

http://rubyvis.rubyforge.org/

glibcの修正方法を議論していてUbuntuの中の人が「んー、このglibc maintainerが提案している方法だと全パッケージのリコンパイルが必要になるよね。それは少なくともDebian, Ubuntuのパッケージングポリシーとしては受け入れがたい」と発言、即座にGentooが「じゃあいつ（全パッケージを）リビルドするの？ 今でしょ！」 などと応じていて笑った。

Gentooさまエー


てゆーか、Gentooの場合リビルドしてるのはお前じゃなくて、個々のユーザーじゃねーかという気もするんだが。

前回、strcpy()は __builtin_strcpy_chk() を使っていて。。という話を書いたので、コンパイラが専用にサポートしている関数しかコンパイル時ワーニングを出せないと理解されてしまう恐れがあると思いここで、補足しておく

以下のgist をみるとわかるように大抵のコンパイル時処理は自前でできる。今のところコンパイル時にstrlen()をする方法が思いつかないので __builtin_strcpy_chk()は無理かもしれないが。

https://gist.github.com/kosaki/5515798

ポイントは

char* my_memcpy_warn () __attribute__ ((alias("my_memcpy_chk")));

attribute((alias))を使うと、my_memcpy_warnをmy_memcpy_chkのエイリアスとして登録できる。
その上で、関数宣言のほうで、

char* my_memcpy_chk (char *dest, const char *src, size_t len, size_t destlen);

char* my_memcpy_warn (char *dest, const char *src, size_t len, size_t destlen)
	__attribute__((__warning__ ("my warning")));

__attribute__((warning))を使って、 my_memcpy_warnのほうだけ呼ばれたら、コンパイル時にwarning出すようにコンパイル時の扱いを変更できる。

んでもって、

static char* my_memcpy(char* dst, const char* src, size_t len)
{
	size_t d = __builtin_object_size(dst, 0);

	if (d != (size_t) -1) {
		if (__builtin_constant_p(len) && len > d)
			return my_memcpy_warn(dst, src, len, d);
		else
			return my_memcpy_chk(dst, src, len, d);
	} else
		return memcpy (dst, src, len);
}

コンパイル時に一意にきまるということは __builtin_constant_p() が trueになるはずなので、場合分けが
出来るのである。

実際、libcのなかではほとんどのFORTIFY_SOURCEの処理はこんな感じで gcc の専用サポートなしで構築されている。