Between "The Dark Knight" and me...

It's me, sat inside the cinema with my girlfriend, Natalia. The movie was The Dark Knight. This time, Batman a.k.a Bruce Wayne face his arch nemesis...The Joker. But this time, I'd like to talk about the complex psychological problems faced by each characters and compared to what already happened to me....the things I have done ...and the future that lies ahead ...

First, let's see Joker. This man....kills ....torch.... blast.....for fun! Now, for a moment, please...just sit down and think, have you ever come into the same mental situation? Maybe you're mad at somebody, maybe it's because your day is filled with nothing than silly boring jobs...maybe you're in serious relationship troubles...bla bla bla. And when you find no way out, suddenly your mind gets crazy and all you wanna do is "the hell with rules, I want to do it my way....my way only...just get out from my way...". You're tired with your live, so you want to break through. And usually you end up with secret mistress, alcohol, brutal sex. And if it's so damn depressing, probably you want to blow your own head?

To tell you the truth, in some part of my life, I have been living with "Joker alike" style. This is not a lie. Well, I didn't slice somebody else' face with razor or knive, but I mad at people like crazy from time to time. Maybe because I stood too hard defending my principles...but in the end.... it makes me as uncontrollable man, ready to unleash raging fury. Even 'til this very moment, that dark side of me is still there. Hiding, sneaking behind the shadow...looking for a chance to once again come up. It makes me nuts...

Now, let's check Harvey Dent...or later we find him as Two face. He's the man who once stand against crime so hard. So hard that he risks everything to put every bad guys in jail. How about you? You think the same way as he is? Then what happened, when you find out that what you have done...in almost your entire life...smashed away because somebody don't really believe in you...or worse, they betrayed you? I can tell you how it's feel. It's like a bullet shot right into your brain. Not only it introduce great amount of pain, but it also makes you hate yourself.

I say, screw with money. I am not saying money isn't important, but is that all you expect as a return for all your work? How about respect? How about trust? How about friendship? How about love? Once I worked on something, solely because I want to share something with other people. But day after day, I saw I didn't really change anything. Things still go bad and community didn't really appreciate me. That's strike two pal.

The last...and the best part, is Batman itself. He thinks it's the time to quit, because harvey in his opinion already do Batman's job nicely. Without acting like vigilante, he puts the criminals behind the bars, so Batman practically and eventually won't be needed again. So, he thinks he can put "Batman" at rest and become normal again. But it doesn't happen. Batman is still needed as Gotham ultimate protector.

Lately I thought the same way. Is it the time to stop everything I have done for years...start living normal...build happy family...and let "the other me" banished? For once....I almost did that. But I can't...at least for now. I still didn't find somebody else with the same level of seriousness, focus and dedication. I believe Bruce is a little bit more lucky in this case, Harvey shows a good prospect...well up until Rachel is dead and he began to uphold justice with his own way.

So, here I am... in front of a PC at 00:00... My head is filled with tons of questions like "is it right?", "why am I doing this?", "I am tired, should I quit?", "I think that was true, but not anymore". I guess the answer could be provided simply by faith to God. Or maybe, like Harvey did, is a matter of believing in chance. 50-50... 50% ... 1:1. It might go wrong or right. It could screw your life or magically make it better. You end up in jail or arise as hero. You meet with a slut or woman of your dream. List can continue but the bottom line is, I think we can not entirely control our life. I learned that the hard way, but then I asked myself "so it's just a matter of luck? Sounds bad..."

Or...maybe... it's because we're just afraid of ourselves. And we create symbols, like Batman... to conquer our fear. Fear of live..fear of being rejected...fear of failure...

PS: Before you leave this site, think of what Harvey said
"You either die a hero or you live long enough to see yourself become the villain"

regards,

Mulyadi.

OK, we got it :)

Oh, this is what I call "up to date news" :D News about bad news ....

Somehow we fixed the same thing...

commit b3da2a73ff5a2953a4ad8ebbf0aa7e6965ff9de2
Author: Mel Gorman <mel@csn.ul.ie>
Date: Wed Oct 24 18:23:50 2007 +0200

sched: document profile=sleep requiring CONFIG_SCHEDSTATS

profile=sleep only works if CONFIG_SCHEDSTATS is set. This patch notes
the limitation in Documentation/kernel-parameters.txt and prints a
warning at boot-time if profile=sleep is used without CONFIG_SCHEDSTAT.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit c0fe2e6964bea897d059fd1680a53cf131546f20
Author: Dave Jones <davej@redhat.com>
Date: Sat Oct 20 03:08:22 2007 +0200

Add missing profile=kvm option to Documentation/kernel-parameters.txt

Whilst looking up what profile=sleep did, I noticed that we missed
adding docs for the most recent addition to the profiler.

Signed-off-by: Dave Jones <davej@redhat.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Adrian Bunk <bunk@kernel.org>

And this was my post to LKML. Maybe I was too slow...but anyway, at least I achieve almost the same thing purely by reading the source code. Now that's what I call working!

regards,

Mulyadi.

My article goes Arabic!

Without further comment, here it is http://arlinux.110mb.com/lgazet/vim-m.php. It's actually an Arabic translation of LG 2 cent tip written by me about couple months ago in 2007.

And Happy Idul Adha...

regards,

Mulyadi

Finding frame rate tester for Linux?

Breaking from my usual routines on posting Linux internals issues, I post something different right now. Since I am also a (near hardcore) gamer, I always pay attention on recent game releases and development. Well, not so intense like the old days, but I still keep my eyes on it.

And for gamers like me, what's the important thing to watch for? Cool GPU? Of course! Feature rich multimedia library? That's another good score. Free but excellent OS as gaming platform? Of course (actually this is a long way to say Linux has bright future in gaming industry). But, in the end, you need a method to determine the perfomance of those pieces combined into a PC. And that's my friend...is our beloved frame rate tester.

In Windows world, finding such tool isn't too hard. FRAPS is a nice example and I bet is the current standart tool for doing GPU benchmark on Windows. It can do fps (frame per second) calculation (min, max, average), do single frame capture, do continous frame captures and save them as movie (raw AVI if I read the FAQ correctly. Eventually you need to convert it as mpeg or divx one to avoid bloating your precious disk space).

So, how about Linux? Wandering in WWW gave me an answer. Looks like the folks at Anandtech had done the job. Framegetter is a BSD licensed to do more or less what FRAPS does. I can't really judge this tool, but from its short intro article, I think it's enough as basic GPU benchmarking tool. The only thing that made me a bit hesitate to try it is the information that the tool will overwrite(?) the games executables. Hmmm, not so polite IMHO. But maybe, what they mean is probably doing something like external function redirection through LD_PRELOAD trick. In that's case, the information is surely misleading. But all in all, I am happy to see this kind of Linux based tool arise in the surface.

Last note: if you wonder how FRAPS work on Windows, maybe you can check Taksi, an open source tool for frame tester. Take a look on its source code....i am sure it will be a fascinating journey.

regards,

Mulyadi.

Peeking into kernel internals with SystemTap

Just to remind myself and others who are interested in kernel instrumentation. Long time ago, perhaps we did it via manual code modification followed by kernel recompilation, or...uhm, have you ever done syscall hijacking or something like that (ok, it sounds dirty...) ?

Now, here comes SystemTap. Some people call it Dtrace-clone. You can find it here. And here you can read a simple example on how to trace boot process. Hungry for more something alike? Go to a section of Daniel P. Berrange website dedicated to boot instrumnentation.

regards,

Mulyadi

observing kernel variable's content with gdb

I put it on my blog, so at least some people could have the alternative place instead of digging kernelnewbies archieves. This is a raw summary of discussion between me and Robert P.J. Day. First, an extensive explanation from Robert:

ok, here's what i've learned so far, and i have to admit, a little
of it surprises me. to explain what i'm doing, i've just started to
write a tutorial on kernel debugging for one of my clients, and i'm
trying to start with the absolutely simplest possible techniques.

the simplest method i know of is just

# gdb vmlinux /proc/kcore

AFAIK, unless you have at least the kernel image, there's not much you
can do (but if there is, feel free to fill me in and i'll add it to my
list).

so, as a first attempt, i used the latest git tree and explicitly
configured *without* the DEBUG_INFO selection. even though LDD3 (p.
100) claims that you need that option to have symbol information,
that's not entirely true.

once i configured and built my kernel, i then had my vmlinux file
and my System.map file, and i rebooted under that new kernel. i could
then compare the contents of System.map to the contents of
/proc/kallsyms, just to verify that it looked sane:

$ grep "D jiffies" System.map
c054bc00 D jiffies
c054bc00 D jiffies_64

$ grep "D jiffies" /proc/kallsyms
c054bc00 D jiffies
c054bc00 D jiffies_64

ok, looks good. and, at this point, as root, i can do this:

# gdb vmlinux /proc/kcore
...
warning: shared library handler failed to enable breakpoint
Core was generated by `ro root=/dev/fc5/root rhgb quiet'.
#0 0x00000000 in ?? ()
(gdb) p jiffies
$1 = 1084958
(gdb) p max_cpus
$2 = 32
(gdb)
...

so even eithout selecting DEBUG_INFO, you can still examine at
least *basic* data objects. what DEBUG_INFO gives you (as i read it)
is the ability to dump more complicated objects, like structures. but
even without that feature, gdb is still moderately useful.

i had always read that you absolutely needed DEBUG_INFO to use gdb
in any useful way, but it's clear that that's not true.

----------------------------------------------------------------------

And I say:

> ok, here's what i've learned so far, and i have to admit, a little
> of it surprises me. to explain what i'm doing, i've just started to
> write a tutorial on kernel debugging for one of my clients, and i'm
>
Instead of "debugging" in its true meaning (dumping values, setting breakpoint, observing stack frames, and so on), if you just use gdb that way (without using kgdb, kdb and etc) we can only dump variables, or possibly anything that just related to passive observation.

And one thing (I just tested moment ago), seems like gdb "caches" the result of "print" command. This is probably related to the fact that kcore is dynamically changed but gdb only check the value of the startup stage. So, "jiffies" or any other dynamic variables seems constant.

> trying to start with the absolutely simplest possible techniques.
>
> the simplest method i know of is just
>
> # gdb vmlinux /proc/kcore
>
> AFAIK, unless you have at least the kernel image, there's not much you
> can do (but if there is, feel free to fill me in and i'll add it to my
> list).
>
>
$ grep jiffies /boot/System.map
c0354644 B jiffies
^^^^^
convert that value to decimal, because AFAIK dd can not accept offset in hexadecimal form.

$ dd if=/dev/kmem skip=3224716868 bs=1 count=4 | od -t uL
We fetch 4 bytes, since jiffies (not jiffies64) is an unsigned long variable. We tell od to display it as unsigned long as well.

For more about this kind of technique, google for "kernel memory forensics".

I hope that recipe is correct. feel free to try that....

----------------------------------------------------------------------

Robert eventually reminds me of this:

>seems like gdb "caches" the result of "print" command.

yes, which is why you need to re-load the core file each time with:

(gdb) core-file /proc/kcore

that will then show you the latest value. try it, you'll see.

----------------------------------------------------------------------

I hope that is a useful info for your all.

regards,

Mulyadi