Scientific Visualization Using imagery to aid humans in understanding a complicated phenomenon

An example from our class Student asked about ‘task_union’ objects “Can stack overwrite process descriptor?” Maybe we ought to be worried about this If descriptor gets corrupted, then: crash! System protects against users crashing But can’t protect if kernel code crashes!

One picture is worth 1000 words ‘modules’ let us study a running kernel We could look at a ‘task_union’ object But there are several design-issues How much ‘data’ will fit on one screen? How can we make ‘data’ understandable? How can we make a picture be ‘esthetic’? How much effort are we willing to devote?

Doing data amalgamation Size of a ‘task_union’ is 8KB Size of standard text screen is 2000 chars Not enough display-space for these bytes Idea: use a coarser subdivision of the data Subdivide a ‘task_union’ into quadwords Each quadword is 8-bytes in size So total number of quadwords is 1024

Screen layout Standard text screen: 25 rows, 80 columns Arrange 1K quadwords: 16 lines, 64 cells Enough room left for a title and a legend data title legend

Module’s design Build a ‘/proc’ module Can use a ‘wizard’ for Rapid Development’ Our ‘proc_read()’ function needs two parts 1) prepare the selected data-amalgation 2) draw screen display: title, data, legend

The ‘amalgamation’ step Use an array of byte-size elements: unsigned charglyph[ NR_CELLS ]; Define manifest constants: #define GRANULARITY 8 #define SZ sizeof( union task_union ) #define NR_CELLS (SZ/GRANULARITY)

Location of ‘task_union’ object We can use value of ‘current’ macro: char*cp = (char*)current; (This creates pointer to the object’s base)

An amalgamation algorithm inti, j; for ( i = 0; i < NR_CELLS; i++) { unsigned chartotal = 0; for (j = 0; j < GRANULARITY; j++) total |= cp[ i * GRANULARITY + j ]; glyph[ i ] = ( total ) ? ‘+’ : ‘-’; }

Algorithm rationale ‘clean’ memory will show up as ‘-’ ‘dirty’ memory will show up as ‘+’ But this won’t show areas we care about! We want to see the ‘process descriptor’ And we want to see the kernel stack

A ‘secondary’ algorithm Mark descriptor cells with letter ‘D’ And mark stack cells with letter ‘S’ But which are these cells in ‘glyth[]’ array?

Glyphs for descriptor and stack Process descriptor starts at offset zero Descriptor’s ‘size’ tell where it ends int d_top = sizeof( struct task_struct )/8; for (i = 0; i < NR_CELLS; i++) if ( i < d_top ) glyph[ i ] = ‘D’; Stack-area ends where task_union ends But where does stack-area start?

Reading cpu’s ESP register For IA-32 architectures, ESP = stacktop Need assembly language to read registers Here’s how to write it for gcc: Declare a memory-variable: unsigned longtos; Copy ESP register-value into variable ‘tos’: asm(“ movl %esp, %0 “ : “=m” (tos) );

‘kernel stack’ glyphs Task kernel-stack begins at address in ‘tos’ ints_org = ( tos / GRANULARITY ); for ( i = 0; i < NR_CELLS; i++) if ( i >= s_org ) glyph[ I ] = ‘S’;

Drawing the screen display Use ‘len’ variable to count output bytes Initialize ‘len’ to zero Draw to area whose address is in ‘buf’ Use ‘sprintf()’ function to draw into ‘buf’ Increment ‘len’ as more bytes are drawn: len += sprintf( buf+len, “\nMy Title\n” );

Use loop to draw data-glyphs Show 64 glyphs per line: for (i = 0; i < NR_CELLS; i++) { if ( ( i % 64 ) == 0 ) len += sprintf( buf+len, “\n” ); len += sprintf( buf+len, “%c”, glyph[ i ] ); }

Understanding and Esthetics Picture looks ‘upside down’ Shows descriptor higher than stack Also doesn’t show where data is located Can we draw it so that: it’s easier to understand? it displays more information? it is prettier to look at?

The visualization ‘demo’ Module ‘visual.c’ is on our course website Compile module using command $ make visual.o Install module using command $ /sbin/insmod visual.o Show ‘task_union’ object using command $ cat /proc/visual

Project #2 Write a Linux character device-driver Driver’s device-file will be: /dev/physmem Will allow programs to ‘read’ physical ram For safety: device should be ‘read-only’ Programs can treat ram as ordinary file

‘Physical’ versus ‘Virtual’ Linux maps physical memory to top 1-GB Physical memory starts from 0x Kernel ‘sees’ it as starting at 0xC Virtual address space 4GB Physical RAM High_memory