Basic System Problem Analysis - August 2003

23
Virtual Space Management Structures
There are two VSOD tables, one for files and one for everything else. Everything that has
a virtual address has an entry in one of the two VSOD tables. These tables are:
VSOD/GUFD table, KSO #201
VSOD table, KSO #53
Both tables consist of entries whose type is “VS_OD_TYPE”. The difference is that the
VSOD/GUFD table, KSO #201 contains both VSOD entries and GUFD entries adjacent
one another.
That means that if you know the address of a GUFD all you need to do is subtract the
length of VS_OD_TYPE from it to get a pointer to the VSOD. Of course you can also
use VAINFO to return that value by providing the virtual address of the file, for example:
$20b ($70) nmdat > fv ca12cda8 'gufd_t.file_vir_addr'
2e4.0
$20c ($70) nmdat > wl vainfo(2e4.0, 'vs_od_ptr')
$ca12cd48
$20d ($70) nmdat > wl ca12cda8-symlen('VS_OD_TYPE')
$ca12cd48
It makes sense to keep the VSOD and GUFD adjacent each other for file objects because
when we need to map the object into memory we are going to need to know where the
file is on disk.
Non-file objects such system objects, DST’s and so forth reside in KSO #35 which is
formatted using the same VS_OD_TYPE.
Both file, and non-file objects use identical methods of mapping the secondary storage
image. This is done using several B-TREE’s.
There is what is called an “AR B-TREE” or access rights B-TREE that keeps track of
objects that have variable access rights. An object typically has a single access right (can
you read it, write to it, what privilege level do you need etc.) . Program files, libraries and
stacks are examples of objects that require variable access rights. A stack is actually a
good example, the majority of the stack is accessible by a process running at normal user
mode (ring 3). Portions of the stack, CM as well as NM are protected so you need to be at
ring 2 (PM) or better to write to these areas.
The other B-TREE (non-AR) is for objects that have a single set of access rights.