		  ksos32 Notesfile Table of Contents

 2  File System On-disk Structures        Tom Perrine   3:37 pm  Jan  9, 1987
 3  K_nap and K_receive (Timer Problem?)  Tom Perrine   3:51 pm  Jan 12, 1987
 5  Things to do - device modules         Jeff Makey   12:39 pm  Jan 23, 1987
 6  On-disk and In-memory structures      Tom Perrine   2:58 pm  Jan 23, 1987
 7  VMB.EXE size and boot0 location       Tom Perrine  11:15 am  Feb 11, 1987
 8  VMB.EXE, boot0 and the RPB            Tom Perrine  11:16 am  Feb 11, 1987
 9  VAX TBIA and kernel.gfs               Tom Perrine  12:47 pm  Feb 24, 1987
10  Slot Items, checksums, and packing    Tom Perrine   1:18 pm  Mar 10, 1987
11  IOCtranquilCheck isn't used           Jeff Makey    3:21 pm  Mar 31, 1987
12  XbLcArgSeg is not used                Jeff Makey    3:53 pm  Mar 31, 1987
13  Procedures that are commented out     Jeff Makey    3:58 pm  Mar 31, 1987
14  Initialization Order Problem          Tom Perrine  10:20 am  May  6, 1987
15  PCS access problem (SERIOUS?!?)       Tom Perrine   1:33 pm  Aug 21, 1987
16  KgetSegStatus ignores DA!             Tom Perrine   1:36 pm  Aug 21, 1987
17  PI vectors location problem           Tom Perrine  10:25 am  Sep  4, 1987

-----------------------------------------------------------------

Note 2        File System On-disk Structures         1 response 
Tom Perrine                                  3:37 pm  Jan  9, 1987

Several filesystem items may have to bve changed because the old "bits"
was an actual 16-bit *physical* item, and the new bits16 is a SET, which may
not be packed.

The specific item that prompted this note is allocMap, an ARRAY of bits16.

Or maybe I just need to PACK/UNPACK this sucker as well as the other slot
types??

To Be Continued...

------------------------------

Response 1    to Note 2   
	Jeff Makey                             12:24 pm  Jan 23, 1987  

I think what we want to do is change the allocMap from an ARRAY OF
bits16 to an ARRAY OF bits32 (half as many of them, of course).  Maybe
an ARRAY OF BITSET.  There is some code that already uses the number
of bits in a word as a parameter.

-----------------------------------------------------------------

Note 3        K_nap and K_receive (Timer Problem?)
Tom Perrine                                  3:51 pm  Jan 12, 1987

There seems to be a problem with the interaction of K_nap and K_receive
with a timeout, to wit, there is only one delay value per process.

Yet, how can a process be both waiting for an IPC *and* be in  K_nap??

Someone needs to at least look at this....

SEP (Someone Else's Problem)

-----------------------------------------------------------------

Note 5        Things to do - device modules       
Jeff Makey                                  12:39 pm  Jan 23, 1987

The automatic translation of the KSOS kernel has transformed DEVICE
MODULEes into regular MODULEs, although the DEVICE keyword remains as
a comment.  We need to make sure that critical procedures within these
modules are not interrupted.

-----------------------------------------------------------------

Note 6        On-disk and In-memory structures       1 response 
Tom Perrine                                  2:58 pm  Jan 23, 1987

This is related to the previous note (2) concerning on-disk structures.

REMEMBER THIS:
	All KSOS-32 filesystem "slot items" are the same size on disk,
	currently 102 bytes. This allows 5 slots per block with 2 bytes left
	over. (PHYSICAL REPRESENTATION)

	The on-disk structures ar UNPACKED into the in-memory structures,
	which are defined in terms of the higher-level Modula-2 types.
	(LOGICAL REPRESENTATION)

	The in-memory structures must *ALL BE THE SAME SIZE*, because some
	times when you read a "slot", you don't know exactly what the item
	kind is, and the in-memory structure must be large enough to unpack
	the largest possible kind of slot. IF you dont declare a large enough
	structure in the calling routine, when you UNPACK, it will overwrite
	either the caller's local variables and/or other parts of the middle
	of the stack.

The easiest way to handle this is to recalculate the fillers for the
in-memory structures, so that they are all the same size.

***The assumption that all slot items are the same size is spread
throughout the IO subsystem. The easiest way to reduce the risks is to
re-pad the in-memory structures.***

------------------------------

Response 1    to Note 6   
	Tom Perrine                             3:43 pm  Jan 23, 1987  

I have examined the in-memory structures in IOEform and IOFform, here
are the results:

					current	actual		new
Kind	Name		TSIZE()		fill	bytes		fill

0	mountItem	124		37	87(88)		116
1	emptySlot	108		99	9(8)		196
2	jNode		132		5	127(128)	76
3	indirectItem	108		4	108		96
4	allocSlot	204		0	204		0
5	reservedSlot	108		99	9(8)		196
6	extentItem	128		44	84		120

NOTE.1: All sizes are in 8-bit bytes.

NOTE.2: If there are 2 numbers in the "actual bytes" column, the
number in "()" was calculated by adding up the storage requirements
for all of the RECORD components, and is the correct number.
Discrepancies are due to VAX longword aligning done by the Modula-2
compiler. This aligning is considered when calculating the new fill
value.

-----------------------------------------------------------------

Note 7        VMB.EXE size and boot0 location     
Tom Perrine                                 11:15 am  Feb 11, 1987

With the new release of the console floppy, VMB.EXE got bigger. This moved
the level 0 boot up to 0x4600. Remember this, as it is needed to examine
the boot0 vars from the console.

-----------------------------------------------------------------

Note 8        VMB.EXE, boot0 and the RPB          
Tom Perrine                                 11:16 am  Feb 11, 1987

VMB.EXE leaves r11 pointing to the beginning of the RPB. Boot0 needs
to know this...

-----------------------------------------------------------------

Note 9        VAX TBIA and kernel.gfs             
Tom Perrine                                 12:47 pm  Feb 24, 1987

According to sources at Berkely, moving any value to the TBIA register
used to have the desired effect. However, with the latest microcode/HW
rev., you MUST move a 0 to the TBIA to clear the cache.

the sed script fix.kernel.gfs.sed will handle this properly...

-----------------------------------------------------------------

Note 10       Slot Items, checksums, and packing     1 response 
Tom Perrine                                  1:18 pm  Mar 10, 1987

The KSOS-32 *on-disk* slot items (jNodes, etc.) contain filler bytes
at the end, where needed, to make all items the same size (102 bytes).
These filler items *should be* zeroes, but are not, basically because
they weren't zeroed on KSOS-11. Therefore these filler bytes must be
considered when computing checkSums, and therefore must be
packed/unpacked.

I will now check IOpack to make sure that fillers are packed/unpacked...

------------------------------

Response 1    to Note 10  
	Tom Perrine                             2:20 pm  Mar 10, 1987  

Actually, I needed to calculate the checksum of the PACKED item.
This is all in extio.writej

STC still does not check checksums!!

-----------------------------------------------------------------

Note 11       IOCtranquilCheck isn't used         
Jeff Makey                                   3:21 pm  Mar 31, 1987

The sole call to IOCtranquilCheck is commented out.

-----------------------------------------------------------------

Note 12       XbLcArgSeg is not used              
Jeff Makey                                   3:53 pm  Mar 31, 1987

The two places where XbLcArgSeg is used are commented out.

-----------------------------------------------------------------

Note 13       Procedures that are commented out   
Jeff Makey                                   3:58 pm  Mar 31, 1987

The following procedures are commented out and so were not translated
into Modula-2:

	barf
	MEMcopy
	print_out
	QUEprintOut

MEMcopy is for use in a non-swapping system and the others are debug
output routines.

-----------------------------------------------------------------

Note 14       Initialization Order Problem           1 response 
Tom Perrine                                 10:20 am  May  6, 1987

I have discovered my current problem with MS.10: There is a MODULE
initialization dependency problem with the OSAL module and the swp_pcs
module.

In file KPRc.mod, MODULE swp_pcs, the Process Context Segments (PCSs)
are initialized. For each PCS there is a call to SIRHpcsBuild, which calls
SIRHbuildSuport, which calls OSALalloc to allocate swap space for the
segment.

Unfortunately, the swap space is not initialized until file KSMb.mod,
MODULE SWE. In this module, the size of the swap extent is discovered
and the swap area allocation table (in OSAL) is initialized.

In the Kernel.gfs MODULE initialization list, KPRc occurs BEFORE KSMb.
"Houston, we've got a problem."

Some important questions concerning the construction of the initialization
list by the Modula-2 linker must be answered.:

**How does the linker choose the order of initializations?

**Can it be changed by choosing a different order of files on the link
command line?

**Does it depend on MODULE IMPORT lists?

------------------------------

Response 1    to Note 14  
	Jeff Makey                              7:01 pm  May 14, 1987  

It should be noted that the *linker* (vis., ld) does not choose the
order of module initializations.  Ld can reorder sections of code in
memory, but it cannot change order of execution.  The order of module
initializations is determined by m2l, which then writes this into
Kernel.gfs.

I just did an experiment (see ~ksos/kernel/work/test[12]/test.mod)
where I changed the order of the import lists of two incestuously
interdependent modules, A and B, and a module (test) that depended on
both A and B.  The order of initialization was the *reverse* of the
order of the import lists:

   When test.mod contained		|  When test.mod contained
	FROM A IMPORT ...		|	FROM B IMPORT...
	FROM B IMPORT ...		|	FROM A IMPORT...
   then B was initialized before A.	|  then A was initialized before B.

All of the corresponding .lnk files were identical.

-----------------------------------------------------------------

Note 15       PCS access problem (SERIOUS?!?)     
Tom Perrine                                  1:33 pm  Aug 21, 1987

There is a potential probelm in the Kernel's handling of Process
Context Segments (PCSs). Each PCS is "owned" by user 0, group 0, which
is considered to be a reserved or invalid user id/group.

The problem arises because PCSs are real segments, having a seid and a
label.  Therefore they are namable by any process by seid, that seid
can be used as an argument to a Kernel call, such as KgetObjectLevel,
KgetSegmentStatus, or most important KrendezvousSegment. The label of
a PCS is nullTii, e.g. user 0, group 0, sec 0, int 0, compar 0, da 0.
Such a segment is protected only by virtue of its null discretionary
access mode in conjunction with its owner/group.

-----------------------------------------------------------------

Note 16       KgetSegStatus ignores DA!           
Tom Perrine                                  1:36 pm  Aug 21, 1987

Why does the Kernel call KgetSegmentStatus ignore discretionary access
protection? (The checkDa arg to SACcheck is FALSE!)

An interesting side effect is that you can get the status of a segment
that you cannot get the level of.

This came to light in conjunction with the PCS problem described in
the previous note.

-----------------------------------------------------------------

Note 17       PI vectors location problem            1 response 
Tom Perrine                                 10:25 am  Sep  4, 1987

There is a small problem with the current decision as to where to
place the pseudo-interrupt vectors. In KSOS-11 they were at a fixed
location in low data-space in the supervisor domain. Our current
decision is to place them in the highest-addressed page of P1 space.

The problem with this is that the Kernel currently does not create any
P1 space for a created process. The intitial process is expected to
run in a single segment, as built by SMCLinitialSegment.

The Kernel could be changed to build some P1 space for the process,
but this brings up several problems:

1) is this space just another segment (which means that it has a
seid)? This causes problems not unlike the ugliness with PCSs. Also,
if is just another segment, then could the user map it out with
Kremap!?

2) If it is not a regular segment, i.e. has an entry in the GST, then
where do we keep the information about the P1 space? Could we mark the
segment as "special" in the GST making it invisible to user processes?
If so, this would make it easier to use this "special P1 space
segment" as a place to put the PCS at a later time. However, this
introduces even more ugliness into the Kernel.

What will we do? What *will* we do?

------------------------------

Response 1    to Note 17  
	Tom Perrine                            10:18 am  Sep 16, 1987  

The PIV page has been allocated as part of the PCS structure, in P1 space.
This has several advantages:
	the user can't remap it OUT, causing Kernel grief
	its always there
	it has a well-defined location
This has several disadvantages:
	some special case code in the Kernel to handle this area
		(mostly in PCSsanitize)
	I had to allocate physical mem via MMpart1 for the PCS slots
		(just work that could have otherwise been delayed)

-----------------------------------------------------------------
