whitenoise

technology notes… mobile and embedded.

Archive for the ‘linux’ Category

An Android 101 : Boot and platform init.

leave a comment »

Over the past few months I have been dabbling with Android  SDK and a some amount  of programming.  Sharing what I learnt .

53731_android_101_training_course_vancouver_255255255 

A Linux system:

Apart from the application framework, much of Android uses concepts from Linux directly. This includes file systems , partitions and init scripts (like the init.d). A typical Android device would have the following partitions :

image

Besides there may be some device specific partitions (/modem etc) that the OEMs may use for their own (non –android ) purpose.

Of these ,the recovery partition is particularly interesting. Normal android boot would start running the image in the  boot partition. However if you power on device in the ‘recovery mode’ , you could get started with an alternate boot image (the recovery image).

It was originally designed for OEMs to provide OTA upgrades. But custom ROM makes have come up with custom recovery images  that could flash other kernel images (like CynogenMod etc). A popular custom recovery image is the ClockworkMod Recovery.

AndroidBootSequence

Bootup:

When a normal boot happens, the Android platform starts executing code in the /boot partition .The bootloader then starts the kernel. The kernel does the basic initialization (of hardware ,memory subsystems) before mounting the root file system ( / ). Once / is mounted the ‘init’ process is started.

init.rc :
Like normal (desktop ) Linux systems ,Android init parses and runs the various commands as mentioned in the init.rc  script. The bulk of Android platform init happens here. The init.rc script mounts various partitions , It then starts  daemons like the adbd, service manager (responsible for IPC ).,rild, netd and others.  Finally the init.rc also invokes app_process which actually results in the process called zygote.

Zygote: Every new app is hosted on a dedicated VM. However each VM is not started afresh (not a cold start).  Zygote takes care of loading all system libraries beforehand . When a new app is started ,zygote forks itself to provide a new VM that has most components preloaded .
There is more detail on this here : http://elinux.org/Android_Zygote_Startup

SystemServer:   Once Zygote is fully launched, we have the VM initialized . The platform then starts the SystemServer.(frameworks/base/services/java/com/android/server/SystemServer.java)

SystemServer is the first Java component to run on the system . This module starts all ‘Android services’  like the PowerManager, ActivityManager etc. Once the SystemService completes, Android’s bootup is considered complete.

The platform sends a standard broadcast action called ‘ACTION_BOOT_COMPLETED ‘. Clients that want to do some action once boot up is complete could register for this module.

In the next post I will share about other components of Android , like its IPC mechanism (Binder)  and shared memory implementations (ASHMEM)

[Image courtesy: http://www.techvibes.com/ , http://hmtsay.blogspot.com/2010/10/android-startup.html ]

Advertisements

Written by sujai

November 7, 2011 at 7:15 pm

Memory consumption of your program.A quick and dirty way.

leave a comment »

Happy New Year too all ! Hope the New Year turns out a good one for all of us.

This year,  I would like to write more ‘code’ and blog more about hands on programing tips and topics. With this in mind,  here is the first hands on tip I thought of putting as my first post for the year.

One of the metrics that is measured  in Desktop and Embedded Linux programs  would be its ‘startup time’  and memory (RAM) usage . Owing to its virtual memory , there is no ‘static ‘ way to estimate  RAM usage of a program.

Here is a quick & dirty way to identify the memory consumption your Linux program. This relies on the page-faults that occur as soon as the program is started .

———————
A  gross estimate on the total page faults that happen over an interval by cat’ing /proc/vmstat and look at the page-in count (pgpgin).

As long as your program is the main thing running, and the only work that’s starting up between two checks of that value, the vast majority of those page faults will have been for you.
It’s also useful to look at that value when the device seems to be running sluggishly — when I’ve done that, the page fault count is rising very rapidly, indicating thrashing due to too much memory in use, and too little left for a usable page/file cache.

eg: Before starting your app:
# cat /proc/vmstat
nr_dirty 0
nr_writeback 0
nr_unstable 0
nr_page_table_pages 677
nr_mapped 8151
nr_slab 1231
pgpgin 166187
pgpgout 33
pswpin 0
pswpout 0


After starting app and allowing the initial UI to come up, run the command again:
# cat /proc/vmstat
nr_dirty 0
nr_writeback 0
nr_unstable 0
nr_page_table_pages 711
nr_mapped 8012
nr_slab 1139
pgpgin 172090
pgpgout 33
pswpin 0
pswpout 0

The difference in pdpgin gives an estimate on the memory usage by your application on startup.

So what does these esoteric names mean .Here is a reference on what these terms mean.

pgpgin      –  Number of kilobytes the system has paged in from disk per second.
pgpgout     –  Number of kilobytes the system has paged out to disk per second.
pswpin      –  Number of kilobytes the system has swapped in from disk per second.
pswpout     –  Number of kilobytes the system has swapped out to disk per second.

The following statistics are only available by kernels from 2.6.
pgfault     –  Number of page faults the system has made per second (minor + major).
pgmajfault  –  Number of major faults per second the system required loading a memory page from disk.

Written by sujai

January 6, 2009 at 10:41 am

My tryst with Linux.

with 8 comments

Playing around with my PC was a favorite activity during college. I used to try various OS’s at home .Notable were QNX (provides a host of features including a HTML browser  at a size of 1.44MB Floppy)  and  BeOS (another interesting OS which used to run OpenGL stuff which was otherwise not possible with my  440ZX Motherboard.)

During this time, I came to know of Linux from a friend. The whole idea of installing an operating system whose source code is available for users to change, sounded very attractive . Besides Linux is  based on UNIX. and I always wanted a UNIX environment at home after using SCOUnix for programing at my training institute.

But Linux was notorious for its ‘usability’ issues and installation was not quite easy.  We had to manually configure the mouse, soundcard ,and the gfx card. This was not easy as it sounds. I used to have a diary with all the device names/ model number and IRQ assignments before starting to install Linux.

The first distro I tried at my PC was RedHat 6.2, that came for free with PCQuest. LILO was quite primitve and GRUB was  still in the alpha stage at that time. So the paritions have to be made in windows using some tools like Parition Magic.  Once the partitions are made, it used to be a 1 hour wait (thats what was possible with a Pentium 350 MHz, 32MB RAM) until all software gets installed by the Anaconda installer .

Unlike current versions ,Configuration of display happens almost at the end of the installation.This was most annoying part.  I had an AGP card on my PC and there was no inbuilt support for it in the kernel.XWindows never worked fine for me and I had to work on a 640x 480 resolution.

Fastforward to 2008 and it all seems funny.   Today Linux is a name you cannot ignore and the latest edition from Canonical (Ubuntu Hardy) has an installation procedure that is ALMOST seamless, except for a couple of ENTER presses. As a popular AD from IBM shows, Tux is no more the new kid on the block .

Written by sujai

August 20, 2008 at 2:26 pm

Posted in life, linux

Tagged with , , ,

Creating Shared Objects in Linux- A primer

with 2 comments

Here is some information on the various nuances involved in compiling and using DSO’s in linux.

Lets assume the name of the source file is libhello.c. If we wanted to create a dynamic shared object we compile the file with the following flags.

gcc -fPIC -O2 -Wall -shared libhello.c -Wl,-soname,libhello.so.1 -o libhello.so.1.0

Meaning of the compiler switches:
-fPIC => This is a compiler option that instructs GCC to create Position Independant Code.PIC is a mandatory requirement for DSO’s.
-O2 => This specifies the level of optimisation to be used by the compiler.
-Wall => Generate all warnings.
-shared => This option instructs GCC to generate a shared object library.

-Wl => This is a compiler switch that is used to pass options to the linker .
-Wl,-soname,libhello.so.1 => this string sends the soname option to linker. The soname option sets the ‘soname’ for the shared object. The soname attribute is used by the dynamic linker at runtime to make sure the application loads the correct library.
The ‘1’ in so.1 is used as a versioning for the API’s exposed by the DSO. If we upgrade the API such that its not backward compatible anymore,we should change the number in the soname.

-o libhello.so.1.0 => generate the shared object with name as libhello.so.1.0

Symbolic links to the DSO:
After generating the so, we need to create some symbolic links.

ln -s libhello.so.1.0 libhello.so.1 ==> This link is used by the dynamic linker during runtime .
ln -s libhello.so.1.0 libhello.so ==> This link is used by the compiler when we link this shared object
as -l hello

Why should we have the so.1 and so.1.0 => The 1 in so.1 is used to version the API level changes. The extra versioning in so.1.0 is used to track any change in the DSO (this may not may not break the API compatibility).
Hence we have 2 versions.

LD_LIBRARY_PATH : Includes the directory of libhello to the LD_LIBRARY_PATH,so that the dynamic linker searches for libraries in this path.

ldconfig: The ldconfig command is used if we want to move our libraries to one of the standard system locations. This command also sets the symbolic links that we did manualy. This is a system administrator command .So ,to run this command you should login as root.

The rpath linker option:
Another important linker option used during development is the -Wl,-rpath. During development, there’s the potential problem of modifying a library that’s also used by many other programs — and you don’t want the other programs to use the `development’ library.
To resolve this, we used ld’s ‘rpath’ option, which specifies the runtime library search path of that particular program being compiled.

From gcc, you can invoke the rpath option by specifying it this way:
-Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH)

If you use this option when building the library client program, you don’t need to bother with LD_LIBRARY_PATH other than to ensure it’s not conflicting, or using other techniques to hide the library.

Written by sujai

April 24, 2008 at 11:33 am

Posted in linux

Tagged with ,

Ubuntu Gusty – worth a try.

leave a comment »

The first reviews of Gusty have come and going by the comments there, Gusty is a much better
release especially in the usability front.

The previous Ubuntu release was not so good (no major improvements) and was not so stable for me. Its time to switch to this new release and get my hands dirty on it.

Written by sujai

October 21, 2007 at 4:30 am

Posted in linux

%d bloggers like this: