-------------------------------------------
-------------------- design axiis
--------
----
--
-
-
--
syscalls, a handy comparison axis.

 I call syscalls submissions. There are only a few distinct ones in Ha3sm.
"please" sends text to the Ha3sm in-kernel interpreter. Other submissions,
which must be preauthorized with a please, are for more performant
communication between a process and devices. Parameters are passed in a
sequence at process memory location 0, eliminating CPU machine model
issues. All that need be understood between the kernel and a process is
where the process memory is, which is already necessary, and what the few
submission numbers are. I'm not sure, but I think the system will do the
converting of cell formats that may arise.


----------------------------------------------------------------------
memory mapping and management
	No memory virtualization to mass store. Virtualized addressing 
		memory-to-memory only, probably via segments without 
		paging on x86.
	processes are sequestered (protected from each other)
	processes ask for an exact allotment size, rounded up.
	If that is available they login, else not.
	They can get up to half the largest contiguous area available.
	Virtual memory may be available as a virtual service.


This is coherent enough, but there's a lot of work here. This probably
wants to be in Ha3sm, other than defrag.

Looking on the web a bit, I think what I have in mind might be called 
"first double fit". Allocate the first half of a block twice as big as the
minimum in the request. No pages, whole chunks only. A process gets one 
contiguous expanse of RAM, or doesn't compute.

Keep in mind, Ha3sm is designed to have relatively few processes, and a
H3sm kernel for a shell or whatever is small.

see also memory.html

----------------------------------------------------------------------
permissions/users

The supervisor. Probably the same as the synchronizer, but conceptually
distinct.

No rwx. Access to a thing is yes or no for all of rwx at once.
Information freely _goes_ up-priviledge. Groups are achieved by
giving out passwords to numerous individuals for the same account. Guests
are private vis-a-vis each other, naked to 0wner, and what info 0wner
affords guests is to be needs-to-know basis. If a please mentions
something the guest has no perms for, it's "feature or authorization
non-existant". (Perhaps a group account could require a 2-name login
just for intra-group guest logging.)

The supervisor is the perms management system. It needs secure storage of
passwords. A server box needs a secure device for the purpose, which may
be e.g. a floppy drive.

I read recently, in Tanenbaum I think, that it's proveably impossible to
prevent complicitous processes from exchanging knowledge of each other to
each other. Wierdness can be caused that another process can observe as
anomalies in it's environment. Therefor various monitors are advised for
such activities on server machines. Extra-guest info transfer attempts
should be policed, to an extent and by means that can and should vary per
system. Such utilities are "sentinels", but are addenda to the OS itself,
but bear mention here. Not publishing a standard set of such things makes
them less predictable to the mischievious. Such is the art of the admin.

So it's 0wner/guest, and 0wner knows all, can write any. Guests with
device access to real devices would then be by guest-list? device guest
account? Unnecessary? All 0wner processes together are analagous to
AmigaDos, preemptive multi-tasking single-user. The guest spaces are
ancillary to that. Guest processes are analagous to unix command
interpreter shells. They might have graphics capability, but I'm not
concerned that they do. The system provides such shells with a
permissions-limited Ha3sm interpreter, i.e. a H3sm. This may be accessed
by some other type of code.

Virtual devices are instantiated per authorized guest. So it would be with
guest-specific directories, filesystems or block devices.

One login per guest. A person may login as self simultaneous with device
accounts they may have, such as ernie AND httpd. They can share state
between those local to themselves. Certain accounts may not require a
pass. Groups are a login with one password and two users, the groupname
and a valid user name. Groups run as the groupname guest.

We thus have a block device with guest/passwords/devicelists. 

THIS IS NOT COHERENT YET

recap

Unix is a grand hotel. Ha3sm is a bed-and-breakfast, with wings.

	perms are per guest per device, all or none, devices may be virtual
	hmmmmmmmm, that's keeping the matrix with the guest info, and it's
	a 1-D matrix.

	0wner is 0wner, dude.


----------------------------------------------------------------------
boot-init sequence
	boot
		load at 0x7c00
		nosurprises
		get into pmode
	init
		set up a floppy, keyboard, and VGA BIOS gtty. Or two.
			keyring
			VGABIOSgtty&#
			(could be all the way live at this point.)
		see what other goodies are in ROM (implies string-scan)
		remap the PIC
		hard locate ticker, port 0x48 (pg. 685 TIPCHB)
		init ticker, 0x4b and 0x48
		set a period and a pulse 
		unmask NMI, bit 7 port 0x70
		have a default response for all events
		install some other responses, particularly to offenses
		surprises	(somewhere in here. Where exactly might be
				tricky.)
		put up an 0wner Ha3sm on the keyboard and a local screen
		put up a virtual devices service for guest's storage
			This might be where passwords go
	admin/config
		put up a net services listener, etc.


----------------------------------------------------------------------
build-modify sequence
	from alien OS...
			install a sh
		loop
			add mods and configgies to Ha3sm
				and/or osimplay if desired
			build
				build osimpa 
				build Ha3sm
			start Ha3sm
			test and modify interactively
			keep notes
		to loop
	until alien OS is no longer needed. 


----------------------------------------------------------------------
time/bus access
	hardware generated
		no warning
			surprises
				device signals
				CPU errors
				protection issues 
		synchronizer controlled 
			pulse is periodic, no delay. Priority maximum.
			preempt (implies wake)
	synchronizer generated
		install/hook
		dismiss
		login/logout
	process generated
		submit		please, read, write...
		sleep


----------------------------------------------------------------------
reflexiveness
	This is Fare'-ese for "can read its own code" I think.
	keep it simple
	the kernel has an interpreter


----------------------------------------------------------------------
heterogeneity
	I mean CPU-heterogenous on one bus
	processes have to run in binary on the local machine
	the local machine might have various processors
	there might be a H3sm compiler for each CPU type
	Under no circumstances will submissions require CPU type knowledge;
		submission parameters are passed at a known address 
		(0 probably) in process memory.


----------------------------------------------------------------------
portability
	Installs to x86 with a unix shell. Other arches look very doable
	with the same assembly source. Yes I mean portable assembly.


----------------------------------------------------------------------
abstraction
	Ha3sm is written in osimplay. That means Ha3sm can know osimplay 
	compemble-state constants, addresses and so on, I think. 
	The problem is going the other way; osimplay knowing about Ha3sm.
	Avoid that.

	All the Ha3sm that needs to be written can be written in the 
	intermediate form used for the H3sm interpreter. There one can
	even pass osimplay stuff to the H3sm VM. I think.

