[prev in list] [next in list] [prev in thread] [next in thread] 

List:       klik-devel
Subject:    Re: [klik-devel] strace question
From:       "Ng, Cheon-woei" <cheon-woei.ng () intel ! com>
Date:       2008-01-21 7:05:51
Message-ID: F8A0EBD0F30CA24B974BD57423860EAE04DC6B4C () orsmsx415 ! amr ! corp ! intel ! com
[Download RAW message or body]

Hi Lionel, 

Thank you for your excellent explanations!  I wish to understand how fuseios and \
fakechroot works in the source code level by following the code paths, but without \
doing too many grep.  May be using cscope or doxygen would help?  Do you have any \
other suggestions?  Thanks!

Sincerely,
Cheon-Woei Ng



-----Original Message-----
From: Lionel Tricon [mailto:lionel.tricon@free.fr] 
Sent: Sunday, January 20, 2008 9:17 AM
To: Ng, Cheon-woei
Cc: klik-devel@kde.org
Subject: Re: [klik-devel] strace question

Hello,

Well, it depends of what you want to understand about klik2.

You need to evaluate separately the klik2 python base code (the build and gui 
part) and all the stuff behind (fuseiso, fakechroot), the backend (run) part.

The main idea is to union the real root fs and all files located into an 
iso 'cmg' file into a single mount point (thanks to a patched fuseiso 
utility).

Fakechroot is used mainly to put the previous mount point under a jail to give 
the illusion for the program we want to execute that it runs under the real 
root fs (which is not true). Since special files and /proc are not emulated 
by fuse (for some security reasons), we have hacked fakechroot (based on 
LD-PRELOAD) to give direct access to a list of directory (/proc, /dev, ...).

If you strace kwrite, for example, under klik and the shell mode, you should 
got the following :

lstat64("/tmp/klik/bDEm_j.execute.xvier_1.0-7.3.cmg/home/lionel", 
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
chdir("/tmp/klik/bDEm_j.execute.xvier_1.0-7.3.cmg/") = 0
access("/tmp/klik/bDEm_j.execute.xvier_1.0-7.3.cmg/home/lionel/.kde/share/config/kwriterc", \
 W_OK) = 0
open("/tmp/klik/bDEm_j.execute.xvier_1.0-7.3.cmg/home/lionel/.kde/share/config/kwriterc.lock34ee8a.tmp", \
 O_RDWR|O_CREAT|O_EXCL, 0600) = 13

It appears that instead of reading files/directories from the real fs 
(/home/lionel), fakechroot overload all path with the union path 
(currently, /tmp/klik/bDEm_j.execute.xvier_1.0-7.3.cmg) to 
give /tmp/klik/bDEm_j.execute.xvier_1.0-7.3.cmg/home/lionel.

Hope that what you were looking for. Don't hesitate to play with fuseiso and 
fakechroot to learn more about all klik technologies.

For example :
$ mkdir -p /tmp/app/1
$ export PATH=/opt/klik/bin:$PATH
$ /opt/klik/bin/fuseiso -n -u /home/lionel/Desktop/xvier_1.0-7.3.cmg /tmp/app/1/ 
$ export LD_LIBRARY_PATH=/opt/klik/lib:$LD_LIBRARY_PATH
$ export FAKECHROOT_BASE=/tmp/app/1
$ export LD_PRELOAD=libfakechroot.so
$ cat /recipe.xml

Here, you should obtain the content of the recipe.xml file located at the root 
of the iso file.

If you unset the LD_PRELOAD env var :
lionel@kubuntu:~$ unset LD_PRELOAD
lionel@kubuntu:~$ cat /recipe.xml
cat: /recipe.xml: Aucun fichier ou répertoire de ce type

To unmount it :
$ unset LD_PRELOAD
$ /opt/klik/bin/fusermount -u /tmp/app/1

The python code is 'only' a graphical frontend to all of these commands :-) 
But a very nice frontend indeed !!!

Lionel

On Saturday 12 January 2008 01:37:57 Ng, Cheon-woei wrote:
> Hi Kurt,
> 
> Thank you.  I am not sure if this if what I am looking for.  I want to
> understand how klik works in the source code level, like
> 
> Klik path_to_cmg would call klik.execute_cmg
> Klik.execute_cmg would in turn calls klikExecute(self), then ex.execute
> Ex.execute would calls self.__prep
> __prep would call self.mount_cmg
> So on and so forth.
> 
> Other than reading the source code line by line, is there any good/more
> efficient way (other than using strace) to understand code path?
> 
> Thanks again! Have a great weekend!
> 
> Sincerely,
> Woei
_______________________________________________
klik-devel mailing list
klik-devel@kde.org
https://mail.kde.org/mailman/listinfo/klik-devel


[prev in list] [next in list] [prev in thread] [next in thread]