================== On executing different kinds of executables =================

execsw[] contains pointers to dispatchers for different types of execitable files. Its role
is explained in pp. 93--95. 

Definition:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/exec.h#172

Usage: look for  findexec* methods in:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/exec.c

Finally, in gexec() on line 560, 656 we use the switch.

Speaking of exec(), note how the stack for it gets built, lines 1236--...

Interesting to note: a stack mapping cache optimization, 1807--1816

Some of the per-executable-type data structures: esw and esw32 in elf.c,
(uts/common/exec/elf/elf.c), jexecvsw in uts/common/exec/elf/java.c, etc.:

http://src.opensolaris.org/source/search?refs=execsw&path=%2Futs%2F&project=%2Fonnv 

Obeserve difference parts ("segments") of the ELF file being loaded, or, rather,
mappings for them created, in mapelfexec():
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/exec/elf/elf.c#1126

Ehdr is ELF file header from the ELF specification,
Phdr is the "segment header" structures from the ELF spec.
Observe how the different segments are handled based on their type constants
in the switch at line 1187. 

Type constants here correspond to segment (not section!) types shown by "readelf -a <file>",
but the mapping between sections and segment is shown by "readelf -a"
right after the program headers. E.g., the PROGBITS type sections end up in the 
PT_LOAD (or just "LOAD" as shown by readelf) segments.

There are many other interesting points in this file -- look though it.

================= How OS calls fit together across subsystems =================

From segment drivers to FS and back:


Observe the "dives" from abstraction layers to specific systems' implementation
workhorse methods and back:

mmap in systent.c -> smmap64() in uts/common/os/grow.c -> smmap_common()

Much of smmap_common() is checking permissions and various cases
of mappings as defined by the passed arguments (see "man -s2 mmap")  

   on line 761 you see the actual redispatch to the worker
    function pointed to by the vnode, and from it to
    the actual file system driver's imlementation:

     VOP_MAP(...)

   For example, for an mmap-ed file this could be continued as

       -> <fs>_map() -> segvn_create() -> hat_map()
           ufs_map
           zfs_map
           ...


The device-specific part or the work is handled by device driver methods,
gathered for a device in function pointer structs, lines 905--936.

In particular, line 915 points to mmmmap(), a simple function that handles
mmap-ing of /dev/mem, /dev/kmem and /dev/zero:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/mem.c#744

phys_install is the list of "memlist" structs that specify available 
ranges of contiguous physical RAM addresses.
It is a short list, and hence searched linearly.

Devices get their device-specific worker functions looked up by their
major number, e.g.:

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/vm/seg_dev.c#3147

(recall a DTrace example that looked up device names by their major number in Lecture 2). 
  
Suggestion: DTrace mmap-ing of /dev/zero (e.g., by "dd if=/dev/zero of=somefile bs=1K count=1").
Follow the idioms of  mmap-cat.d  to probe the calls to various methods of /dev/zero .
Using stack() for the probe actions will show where the calls come from.

======= Seg_vn driver for file-backed and anonymous (heap) mappings: =================

Seg_vn driver is responsible for mmap-ing files and anonymous pages. 
It is described in Ch. 9 of the text.
 
Note the use of segvn_create above.

In particular, when faulting in a file-backed page (see text, pp. 478-482):

trap() -> pagefault() -> as_fault() -> segvn_fault() -> <fs>_getpage()


Named in Table 9.4 (p. 479), code in 
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/vm/

Primary example: "seg_vn":
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/vm/seg_vn.c

Observe *static* methods of this driver being packed into a "struct seg_ops",
called segvn_ops, actually assigned at
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/vm/seg_vn.c#780

Note that "struct seg"'s s_data member in segments created by segvn
driver
(http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/vm/seg.h#111)
will be pointing to an segvn_data (p. 482 explains it), and thus
through it to the mapped file's vnode ("vp" member) and offset
("offset" member).

The same driver also handles anonymous mappings. In that case, the segvn_data's "amp"
member will be used instead (shown in Fig. 9.11)



======================== Misc ========================

What is XHAT? According to this posting, its existence was a reluctant
compromise for supporting a particular special device:
   http://archive.netbsd.se/?ml=opensolaris-code&a=2006-03&t=1864384

As such, it is not of interest to us, other than as an example of "giant kludges"
that OS kernel developers can be forced into implementing.

A couple of favorite books I mentioned today:

http://www.kohala.com/start/unp.html  -- W. Richard Stevens, UNIX Network Programming, Prentice Hall, 1990, ISBN 0-13-949876-1.

http://homepage.mac.com/pauljlucas/resume/handbook/index.html -- The C++ Programmer's Handbook 
by Paul J Lucas, 1992, Prentice-Hall, ISBN: 0-13-118233-1 

======================== Rootkits! ========================

A Linux kernel rootkit that hijacks control on the path from an execve() call
for a filename to another executable:

http://phrack.com/issues.html?issue=59&id=5#article   

Observe the succession of deeper and deeper points of interception throughout the kernel layers.

Project idea (not very hard): Write one for OpenSolaris :-)