Daily blurbs Mar. 2006


daily blurbs

30 Mar 2006 (Thu)

08:35:13 # Life fighting with kernel-package and new kernel. Latest linux kernels (since around 2.6.16) changed their kbuild setups a bit. Quite a few people are hit by this problem, 359832. Something related to these posts in linux-kernel, perhaps.

25 Mar 2006 (Sat)

15:48:50 # Life Having too many layers of symbolic links. Linux kernel has a limitation on how many times it will resolve the symbolic links. Apparently, you won't be able to 'open' a file which has more than 5 indirections, if you let the kernel resolve the symbolic link. This is a well-meaning limitation to avoid DoS. Unrealistic workaround that come up to my mind such as to hack glibc to stat the symbolic links before opening, or making applications to call canonicalize_file_name before open. Sometimes, this gets annoying.

$ ls -l 
total 4
-rw-r--r-- 1 dancer dancer 5 Mar 25 15:49 a
lrwxrwxrwx 1 dancer dancer 1 Mar 25 15:49 b -> a
lrwxrwxrwx 1 dancer dancer 1 Mar 25 15:49 c -> b
lrwxrwxrwx 1 dancer dancer 1 Mar 25 15:49 d -> c
lrwxrwxrwx 1 dancer dancer 1 Mar 25 15:49 e -> d
lrwxrwxrwx 1 dancer dancer 1 Mar 25 15:49 f -> e
lrwxrwxrwx 1 dancer dancer 1 Mar 25 15:49 g -> f
lrwxrwxrwx 1 dancer dancer 1 Mar 25 15:49 h -> g
$ cat b
$ cat h
cat: h: Too many levels of symbolic links
$ realcsh.c 
REAL csh: #include <stdlib.h>
REAL csh: #define _GNU_SOURCE
REAL csh: printf("%s\n", canonicalize_file_name("h"));

19 Mar 2006 (Sun)

09:48:57 # Life With regards to a writable powerpc linux plt. I've done some research on writable plt on powerpc, and found that it is considered a problem, and is already fixed. New ABI is presented on May 2005, and is merged to binutils, and is included in Debian binutils in sid. Interested parties may want to look at binutils:bfd/ppc_elf_select_plt_layout. However, they need glibc/gcc updates to fully function. Apparently, fedora core seems to already have that.

22:55:48 # Life Venturing into emacs-muse, a wiki engine. I've decided to take a look at emacs-muse (muse-el Debian package). I share many of JoeyH's sentiments with regards to what wiki should have. But maybe that's only an evidence that I'm an old-type. One thing I liked about emacs-wiki (which is what emacs-muse is a fork of) is that it allowed editing of wiki files from emacs, or whatever plain text editor, and allowed viewing of HTML after processing. They are just plain text, and can be controlled with version controlled systems. There was this nifty thing called elserv-wiki, which made emacs a webserver, and allowed wiki editing, but apparently, it's not available for muse yet, and thus I can't make it a fully-fledged wiki engine. I'm slowly exploring the space. Apparently, emacs-muse doesn't really work right now for Japanese PDF generation, somebody needs to hack on it. HTML output works, so no problem right now. RSS output seems to be unavailable, along with handling of ChangeLog which used to exist in emacs-wiki. Anyway, I converted tokyodebian project webpage to emacs-muse, rather than hand-crafted HTML, and I'm happy.

13 Mar 2006 (Mon)

07:41:11 # Life How costly is a shared library function call compared to a static library function call? Linux/glibc/ELF shared library function calls are said to be slower than static library function calls, because function calls a redirected through plt/got section, which jumps to addresses specified by the offset in GOT. The background for this indirection is that ELF specification implies that load address of a shared library is not pre-determined, and addresses are decided after load. To make this happen, allowing write to the whole text segment (where all the code is, including jump addresses and other things) will disallow read-only mmap of executable binary. That means backing store is required in terms of swap space. To minimise the effect of modified jump instructions, the modifiable jump instructions are split off into another section, which is writable all the time, called GOT. (this is my understanding, if you find any corrections, please send me a mail, so I can secretly update this page). Anyway, there's an extra jump instruction involved for shared library function calls. I made a short micro-benchmark and measured the time required to make sure that was the case. I called function call for 1G times on a 500MHz powerpc. Apparently, it takes 2 clock-cycles of overhead.

shared library static link
real 17.646 13.746
user 17.005 13.233
system 0.024 0.018

The branch instruction written to plt section was like this (powerpc):

0x10011b70 <function_in_lib@plt+0>:	b       0xffdf590 <function_in_lib>

I've done the same test on Athlon 64 2.2GHz, running it for 2.2G times (2200000000). It was also using about 2 clocks.

shared library static link
real 8.185 6.142
user 8.168 6.125
system 0.000 0.002

Happy with the results, I measured the profile information with oprofile. The result was a bit unexpected. Why? To be continued... (maybe)

shared library static link
function_in_lib 61% 25%
main 28% 66%
.plt 4% -

Ian Wienand pointed out to me that GOT is the writable part, not PLT. Apparently on my powerpc system, PLT seems to be modified, but on amd64, PLT is just a table of jumps, and GOT is the table of addresses. He pointed me to this excellent article. Of course, I should have looked at my own article which talked about GOTs.

I've checked, and it looks like the plt section is modified in powerpc, I'm not too sure right now.

(gdb) disassemble 0x10011b70
Dump of assembler code for function function_in_lib@plt:
0x10011b70 <function_in_lib@plt+0>:	li      r11,4
0x10011b74 <function_in_lib@plt+4>:	b       0x10011b40 <_GLOBAL_OFFSET_TABLE_+44>
End of assembler dump.
(gdb) cont

Breakpoint 2, main (ac=1, av=<value optimized out>) at main.c:50
(gdb) disassemble 0x10011b70
Dump of assembler code for function function_in_lib@plt:
0x10011b70 <function_in_lib@plt+0>:	b       0xffdf590 <function_in_lib>
0x10011b74 <function_in_lib@plt+4>:	b       0x10011b40 <_GLOBAL_OFFSET_TABLE_+44>
End of assembler dump.

12 Mar 2006 (Sun)

15:57:04 # Life I've loaded a midi file with rosegarden. I noticed that the beams weren't set properly. Would it be possible to improve this algorithm? When I imported the MIDI file to rosegarden4, it gave me the following:

I really wanted something like (which better matches the beats):

10 Mar 2006 (Fri)

00:36:23 # Life What have I been doing in this monthly Debian meeting in Tokyo? I don't know if there are many LUG meetings around the world, but I tend to like face-to-face interactions with people. That's why I keep on doing monthly meetings for Debian developers, and future Debian developers in Tokyo. Here is a PDF of what I used as presentation for Debian-weekly-news-quiz, quickly translated to English for the world to have a feel of what it looked like. They are usually in Japanese. This is the kind of thing I have been doing for the last 14 months. Note that the quizzes are meant to be trivial, and meant for provoking some discussion in the face-to-face meeting. Kudos to Joey for the excellent Debian Weekly News, which the quizzes have been based upon.

8 Mar 2006 (Wed)

01:58:56 # Life soundtracker package update. Although there are quite a few pending things with soundtracker, since it's a new upstream release, rejoice. I've updated Japanese translation for the package, and found several upstream packaging bugs, but all in all, it's a functional tool, which is pretty decent. Nice.

5 Mar 2006 (Sun)

22:45:40 # Life memory leak detected with setenv. I've been playing with putenv/setenv, and wondering how those two differ. setenv looks more convenient indeed. However, setenv seems to allocate memory to construct the environment variable string, which is not acceptable. It took me a while until I really found out the problem with this code.

4 Mar 2006 (Sat)

00:36:07 # Life soundtracker on 770? I received an inquiry if soundtracker will work on Nokia 770. Looking at the specs, it doesn't sound like it's impossible, might have performance issues related to FPU. I am not quite sure if it will run fast enough (as in being able to play-back MOD files real-time) with a floating-point emulation, and not sure if it has a FPU. Even if it had a FPU I'm not quite sure Debian package will have FPU support. Nice project to experiment, though.

21:56:44 # Life libpkg-guide in PDF format? I received a mail asking if libpkg-guide is in PDF format. I checked, and saw that it's not available, but I have a reference to a PDF file in the Makefile. The hooks are there, but it was just not published. I built the PDF, and looked at it, and looked away after several seconds. It was ugly. All the tables were broken. It's built through dxml-db2latex, but that's not actually a very good docbook-to-latex translator. I wonder if there is a good docbook-to-PDF translator? debacle told me 'db2latex' is usable, I tried; and it indeed does look much more beautiful. Thanks for those who had helped, I managed to get libpkg-guide into PDF, although it was locally getting too late at night... Phew. Things sometimes move too fast for me.

23:12:11 # Life autopkgtest and pbuilder. While I was reviewing Debian Weekly News translations, I noticed there was autopkgtest. Nice to see something that emerging to be available. I've already written quite a few tests for pbuilder testsuite, so it's unwelcome in terms of having a incompatible test interface. Browsing autopkgtest, it's non-obvious how to write the tests, or how to use it, so some documentation is probably required. pbuilder testsuite has been deployed on quite a few of my packages, so I have some insights. It's pbuilder, so it's slow, but if it's included in the automated workflow (kick off build -- automatically-test -- upload), it's not too bad. The basic tests that can be done are console based tests like running ldd, and giving it some input to get some output. The tests are in source-code debian/pbuilder-test/, and are just shell scripts run through run-parts. The following is a rough list of things that I've done:

I've not yet done much GUI testing, since I am yet to find a usable GUI automatic testing tool.

2 Mar 2006 (Thu)

08:20:53 # Life Filing bugs on portaudio. Portaudio license has a vague 'request' to submit changes to upstream, and some confusion has been running on whether this license is DFSG-free. It's actually in Debian as portaudio and audacity package. I've filed bugs to track these reports and find out what's come out of this discussion. 354898, 354899.

The bug was then later downgraded to wishlist by vorlon. I don't think the current status is good, but at least I've done my share, I'm not bothering to do any further myself. Leaving it to the maintainers and the upstream.

1 Mar 2006 (Wed)

18:30:20 # Life I'd like to go and delve into audio programming. There's a lot of APIs around audio programming in Linux. I'll try and see if I can find out more about their inherent designs, and better understand the implications of packaging them.

Junichi Uekawa

$Id: 200603.html.en,v 1.21 2006/03/29 23:42:00 dancer Exp $