A road named NoNameUno

Lot of OS provides ready APIs for stack walk programmatically, that can give us a trace like stack snap-shot when something go wrong and your application crashes. Most popular OS provides debugger and trouble shooting features that can help determine where and why something went wrong.

But it is not a piece of cake when you think you have to craft something right into kernel, and watch how things are happening. This is deep probe in my belief. So here are some background work that needs to be considered first --

-- why do we need to do. In other words, why am I here ?

-- What are the known and unknows? It could be a wide range of knowledge in general computer science.

-- How can I get some control of the kernel ?

-- How best I can craft a stack walk ?

-- What to look after I know that stack walk is working somewhat to my satisfaction ?

I've been able to finish this project/investigation and can see the result first hand.

-pro

Time flies, and we are just about to enter another year. Time and again I bumped into this thing we call stack back trace. For last 10 or so years I always thought that it would be nice to get good grasp of this lethal weapon, compareable to a sharp knife and sharper brain of a surgeon. If one can understand this then lot of todays technology and their underlying thoughts and implementation becomes clear.

One can use it for lots of different things. Debugger uses it all the time, so it is not a new ground breaking technology. But its use is unbelievably wide in range. In this continuing series of notesf, I will try to emphasize one such implementation, that perhaps some of us could call "Beautiful code", and some of its use. It will cover an wide range of topics like: assembler, symbol constructions, application binary interfaces and standards, register sets and its purpose with respect to activation records.Finally its incarnation into the kernel.

More coming ...

We are nearing the end of 2016, and holiday season is around us. I've appreciated code that by looking at it, I can tell it is well written. Then are some of them in the category of Beautiful code !

When I read a small article or a short stories about anything, if it can hold me engaged and I understand the flow and theme without much effort, I call it beautifully written. I've always thought about my writing that I could call beautiful code even merginally!

I recently wrote something to tackle some xnu virtual file system code that can alter program behavior depending how nice or rogue that program. So there was a deep dive into the xnu kernel code. The idea is to take early control of program execution, and see if it make sense to let a foreign program to play on your backyard.

As it turned out that depending on core kernel changes, there could be few things that needs to be checked even if I can not decide if it is going to harm or not.

So the idea, that it will make sure it keep a tab on those undecidable situations and learn of them on the fly. It will learn some traits that will drive the decision to take control.

I call this beautiful code, since it is a passive observer of the traits of foreign programs without even knowing by anyone its presence. Since it is in the kernel, it must be fault proof.

lsb_release -a     // ubutu version 

From anywhere in the desktop - Cntl + Alt +T to get a terminal.

lspci    //pci devices

lscpu

lshw -short

hwinfo

lsscsi

lsusb

inxi

dmidecode

# display information about the processor/cpu
$ sudo dmidecode -t processor

# memory/ram information
$ sudo dmidecode -t memory

# bios details
$ sudo dmidecode -t bios

lsblk

df

sudo fdisk -l

pydf

mount

free -m

# cpu information
$ cat /proc/cpuinfo

# memory information
$ cat /proc/meminfo

cat /proc/version

$ cat /proc/partitions 
major minor  #blocks  name

   8        0  488386584 sda
   8        1   73400953 sda1
   8        2          1 sda2
   8        5  102406311 sda5
   8        6  102406311 sda6
   8        7    1998848 sda7
   8        8  208171008 sda8
  11        0    1048575 sr0
 
$ sudo hdparm -i /dev/sda
 
 ps commands --

ps aux

ps -ef

Use the "u" option or "-f" option to display detailed information about the processes

ps aux

ps -ef -f

To filter the processes by the owning user use the "-u" option followed by the username.

 Multiple usernames can be provided separated by a comma.

$ ps -f -u www-data

To search the processes by their name or command use the "-C" option followed by the search term.

ps -C apache2
To display processes by process id, use the "-p" option and provides the process ids separated by comma.
$ ps -f  -p 3150,7298,6544
Sort process by cpu or memory usage

$ ps aux --sort=-pcpu,+pmem

Display the top 5 processes consuming most of the cpu.

$ ps aux --sort=-pcpu | head -5
Display process hierarchy in a tree style

$ ps -f --forest -C apache2
Display child processes of a parent process
$ ps -o pid,uname,comm -C apache2
Display threads of a process
$ ps -p 3150 -L
Change the columns to display
ps -e -o pid,uname,pcpu,pmem,comm
$ ps -e -o pid,uname=USERNAME,pcpu=CPU_USAGE,pmem,comm
Display elapsed time of processes
$ ps -e -o pid,comm,etime
Turn ps into an realtime process viewer








watch -n 1 'ps -e -o pid,uname,cmd,pmem,pcpu --sort=-pmem,-pcpu | head -15'

Being trained in Graph Algorithms, Netwrork optimizations, stochastic calculas including queuing theories, I've been drifting around networking area for almost all my working years. But my own networking ability is immensly poor !

Just about 25 yrs ago, I was dealing with general network design/model to charactrise different metrics to measure certain known user perceptible networking traits. As a result, we were even able to produce some nice parametric results that showed up in conference papers. In particular, back then the micro controller based memory was quite expensive, and a mega bytes costed bit of extra money. So we had to model to comeup with estimated range of memory needed for network components thruout a network.

Without getting into details, we already had a sliding window protocol in place for receiver to advertise what it is capable to take within then next epoch. And sender will adjust itself based on the receiver's indication to sender. At that time I used to talk about how we could make Etiquette being a protocol. Hence the name of this post.

But the wave of high-tech revolutions took me off the track quite a few times, as well as perhaps lack of imagination. By the time we were done, only few companies were actively involved dealing with networking protocols, where as lot of companies were interested in platform areas. So it was hard, if not possible to convince that some of the protocols does not have to be the way it is. The perception was that few companies tried their own protocols but tcp/ip prevailed, so why bother ?

Good question, right? Way too many times we hard the mouthful direction - Don't reinvent the wheel. Even a damn illiterate people would advice you the same !

Now proliferation of IoTs and mobile everywhere things are changing. Once again, lot of bright people thinking and tearing apart our beloved tcp/ip protocol stack to comeup with need based design and implementations. What it means to me ?

Trying to find a wonder drug, so that I can retrieve all the lost temoral-memories! But the good sign is that people are now realizing that a protocol designed in late 1970s was good enough then but now we need to deal with present state of affairs.

Happy to see the movements. Will detail later on couple more posts.

Yeah make Etiquette to Protocol!