Stuff Ha3sm will have that unix doesn't
- process memory resident virtual devices (vaguely analagous to
/dev/random and so on, but looking like 0xDFF000 in an Amiga, i.e.
memmapped ports. Each process will have a known-hertz timer in it's
memory-space, at least.
- need-to-know-only process access controls. If you can't use it, you
can't tell if it exists or not.
- A request (syscall) to use the in-kernel H3sm interpreter,
please
- device IO "channels"
- realtime service on the NMI
- multiplexed channel listeners (AmigaDos has this).
- a Forth-like default block device for each process.
- 0wner. All 0wner processes see and share all physical reality.
- Not sure if unix has these, but some interrupt handlers may be
callee-saves. Particularly the realtime tick.
- Hot 0wner console. The basic unix paradigm is all terminals. The Plan 9
paradigm is inscrutable. Ha3sm can know the CRT is on the bus,
for example.
- Stainless guest-process stacks. Above-TOS on a guest process return stack
will not be clobbered by the system, only by the guest process.
- per-guest H3sm interpreter. Guests will not have dictionary-linking
knowledge, but can do "words", and define new words in thier
kernel-services dictionary. This is functionally the same as Plan 9 file
namespaces.
- Persistant user-customizable user-words.
- Text-and-pseudocode please interpretation. ASCII UNIT_SEPARATOR
delimiting of interpreter words, ASCII printable whitespace as VM
NOPS.
- phlotes (pyte floats) service in the kernel. ACK/NACK field in phlotes
stack buffer metadata.
Stuff unix has that the Ha3sm kernel won't
- files
- default "IO" for every process
- parent-child process relationships
- signals?
- build requirements that can't be built with just a shell.
And maybe, like, cat.
- "root". See "Owner".
- sub-channel access controls.
- rwxrwxrwx perms. Channels are read or write, and you can see one or
not. As to groups, give several people the same user info.
- /dev. No files. You address devices initially via a "please".
- Paged virtual memory. Ha3sm will have segmented virtual addressing for
guest processes, but no virtual memory on spindles.
- Out-of_Memory issues. If a process can't get the real RAM it wants it
won't be allowed to "login". Bloaters beware.
- Device number allocation issues. Channel names are text.
- I might get by without signals, due to the virtual devices in process
memory. The issues of process timing and IO are thus kept separate, and a
process can be more passive about a resource. To a process, then, nothing
blocks. Most applications programs will probably be event-driven off a
poll-and-go loop. This is very much in flux.
Stuff that is analagous, but re-factored in Ha3sm
- Processes are spawned by login. Spawn-time is when user
controls are asserted. Guests may be limited to one process each,
maybe. Processes will probably tend to be fewer than in a unix.
- A user has a "words", including channels it can see. This is like
ACLs, but per user. UCLs integral to the syscall interpreter.
vis-a-vis unix (AT&T V7) syscalls
IV is Implicit Local Virtual Device
JQP is John Q. Ha3sm Process, either 0wner or guest
AT&T V7 unix Ha3sm
indir = 0. ?????????
exit = 1. please logout (or divide by zero or something)
fork = 2. please login
read = 3. read, recieve
write = 4. write, send
open = 5. please read, write, send, recieve
close = 6. please close
wait = 7. typically wait for child to die, n/a. JQP can poll-halt
on an IV intra-process.
creat = 8. please "bla" create channel?
link = 9. multi-name channels?
unlink = 10. "forget"?
exec = 11. n/a
chdir = 12. n/a
time = 13. IV
mknod = 14. 0wner-only word, OR implies virtual channels
chmod = 15. 0wner-only word
chown = 16. 0wner-only word
break = 17. n/a, Out of RAM? Tough.
stat = 18. implicit to channel init pleases
lseek = 19. n/a
getpid = 20. 0wner-only word
mount = 21. n/a
umount = 22. n/a
setuid = 23. 0wner-only word
getuid = 24. 0wner-only word
stime = 25. ?
ptrace = 26. 0wner-only word
alarm = 27. poll your timer.
fstat = 28. n/a, file stuff
pause = 29. halt instruction
utime = 30. IV
smdate = 30. IV
stty = 31. you either have a vtty or not.
gtty = 32. you either have a vtty or not. (getty needs this?)
access = 33. ?
nice = 34. 0wner-only word
sleep = 35. halt
sync = 36. flush file buffers, n/a. May have blocks equiv.
Chuck does.
kill = 37. 0wner-only word
csw = 38. ???????
setpgrp = 39. n/a
dup = 41. why do we need 2 IDs for one channel?
pipe = 42. implies virtual channels
times = 43. ?
profil = 44. 0wner-only
setgid = 46. n/a
getgid = 47. n/a
signal = 48. don't know yet if I must
acct = 51. n/a
phys = 52. ???????
lock = 53. n/a
ioctl = 54. please is general
reboot = 55. 0wner-only word
mpx = 56. ???????
setinf = 59. ?????
umask = 60. 0wner-only word
getinf = 60. ?????
n/a IV music coordinator
/dev/random IV random (seed)
/dev/zero IV zero, occaissionally zeros the cell
n/a IV mirror device, bitwise mirror-images cell?
(saves some RAM. pfeh.)