I'm reading EOR; I am recording notes on the experience because I have this idea that a first read is different from any other read, due to the reader's ignorance.
Some of the questions I ask in here are answered further on; I just don't know it yet. It may be worth considering whether it is a good idea to reorder the material. Other questions I ask in here don't really need to be answered, although of course I'd be interested in the answers; I may get around to finding them in the source one of these days.
Some of the things I note are actual errors.
No doubt anyone who reads this is going to conclude that I'm a moron; please go easy on me. :)
This email is very long and boring, I'm afraid. ;)
I hope this is of some use to Jonathan and others.
So here it goes:
- hmm, when reading 1.1 Invocation Types, I was curious about what
actually got passed in an invocation. I would have liked to know that the contents were listed immediately below.
- what are R0..R3 on an x86? Presumably E[ABCD]X? It's hard for me to
think in such abstract terms without having concrete examples first.
- the "send string" and "receive string" say the data can be put in the
architecture's register set if it fits. For RISC processors with large register files (especially those with no register indirection), this would seem extremely disadvantageous; you'd have to save and restore every single register around every single message send. (Well, I guess that's not so bad; the OS has to do that anyway!) Worse, if you have no register indirection, you could end up with 100-way or 200-way branches depending on the length of the string. I must be misunderstanding something here.
Again, I'd like real low-level information here --- enough that I could imagine the assembly code that's being generated when I do a message call or receive. (Or fork.)
- presumably strings shorter than the receive string buffer length get
truncated? Is there some indication of this?
- where are these SK0..SK3 fields? They're keys, so they're not in my
registers before or after sending; do they get written into the node for my domain or something? No, wait, it says SKx and RKx *name* the key registers; so they must be CPU registers, or pointed to by CPU registers. Where are we finding all these CPU registers on the 386?
- is this Key Info field something I can look at? Must be --- it says
the receiving process may assume that the key info field is unforgeable.
- these operation numbers --- are they "order codes" for SR0, or are
they something else? Do the result codes end up in RR0? It looks like it --- OC_Destroy is "destroy order". Are these mnemonics defined in a .h file somewhere?
- hmm, these are like errno values.
At this point, I'm starting to think that key invocations could be mapped into a scripting language like Perl or Python much more easily than Unix system calls could; it sounds like it's fairly straightforward to determine which registers and areas of memory will be used in what way by the key invocation. This could be a huuuge win for EROS --- interfacing random interpreters to the OS requires writing only three low-level routines (well, and something to get space from the space bank), and then everything else can be done in a high-level language.
- looks like some duplication here from the Introduction on the meaning
of TCB, except that here it says "closely held" and "TCB" mean the same thing, while in the Introduction it says "closely held" keys are marked "Restricted", while really sensitive keys that should never be held by untrusted processes are marked "TCB".
- I think the GetObjectKey here is just an example, but I'm a little
puzzled. The "Request" part doesn't mention SR0; does that mean GetObjectKey doesn't support OC_KeyType or OC_Destroy? Oh, wait --- GetObjectKey is an individual operation, not an object. In fact, it looks like it's an individual operation on a Range key. Does "oc=1" mean "SR0=1"? [Yes.]
- Hmm, there's an interface glue layer for C and C++, eh? I guess I
should see if I can figure out which of the other documents it's described in.
- hmm, from the notation, it sounds like most data fields will be small
and simple, not huge and complex; perhaps that should be mentioned in section 1.2.
- a "bignum" is an arbitrary-precision integer, not a mere puny 96-bit
value. That's a malapropism.
- it's going to confuse 386 assembly programmers when you say
"halfword" and "word", because the 386's word is called a "doubleword" or "long" in the 386 assembly jargon --- because the 386 assembly language is a modified version of the 8086 assembly language, and words were 16 bits on the 8086.
- a "client/service}" system?
- both this and the previous page say "it's" for "its". This one says
it three times.
- oh, yummy. some low-level details. On (1A), presumably this is the
reason for the restriction to 64K --- to prevent crashing the system by trying to send more data than will fit in core? ("core" sounds pretty old-fashioned, too. But it gives me a warm feeling because I'm a Unix weenie.:)
- ah, a "key registers node", which presumably has something to do with
SKx and RKx. Presumably the SKx and RKx parameters index into this node.
- on (2): why would you want to invoke a key that points to you?
Won't that hang you permanently if the invocation is a "call"?
- what's a gate key or returner? [answered below]
- presumably memory faults occur always and only when trying to do a
data reference to data not currently mapped into core, right? What's an "accessing call to an address space"? The key-invocation equivalent of a data reference? [Primary Objects.Page says there is no such equivalent.]
- this page says "it's" too.
- you can have pages of keys in the leaves of your address space?
- what are these no-call, read-only, and weak attributes? Is there a
master set of key attributes somewhere that these are among? [See below under Primary Objects.Node.]
- is a gate key one of the types of keys listed here --- for example,
is it a node key? Or is it a different kind of key altogether?
- "previous systems implementing this facility" --- meaning what,
KeyKOS? Are there others? What is "easily obtained"? [According to the Primary Objects.Node and Primary Objects.Page pages, "easily obtained" means you can invoke an operation on a node or page key and get a sensory version of that key.]
- "page faults are considered prompt" --- does this mean that waiting
for a page to be brought in from disk is considered prompt?
- what are these aspects of the design that depend on promptness? I
remember seeing one of them in the keeper section, I think. No --- looking back (which is difficult to do because the pages are so short) I see it was the invocation page.
- so the kernel handles the scheduling, eh? This is different from
KeyKOS, isn't it?
- sounds like the reserve stuff is intended for real-time scheduling
- oh, it's empty.
III, Primary Objects:
- where is the information about which state a process is in stored?
- ah, at last we reach the explanation of key registers, having gone
through sections I and II and half of III needing to know what they were.
- what are "emulation processes"?
Primary Objects.Process.Get Key:
- (0 <= N <= 32) --- what happens when N == 32?
Primary Objects.Process.[SG]et Registers:
- why is the size of the reply message included in the reply message?
Don't we get that automatically from the key invocation mechanism?
- presumably the multiple chunks of the reply definition are all
concatenated, a possibility not mentioned in the Introduction where it defined the syntax of the operation descriptions.
- is RC_Process_Returnee an error? Why?
Primary Objects.Process.Swap Memory:
- why is this useful?
Primary Objects.Process.Make Start Key:
- are start keys a subset of gate keys? [Yes; see Kernel
- It says the request is of format "R1". Letter "R" is not defined in
the introduction. Does it mean "something of the size of a key data field"? What is that size? Does it mean "the key data field normally filled by the kernel when you are invoked"? [It means "in register 1".]
Primary Objects.Process.Make Fault Key:
- why would you want to do this, and why does it place the process in
the "waiting" state? Is this so you can interrupt the execution of the process, e.g. for debugging?
Primary Objects.Process.Make Process Available:
- is this here so you can timeout on requests?
- provides the basic unit of storage for how many keys, did you say?
Primary Objects.Node.Check Alleged Key Type:
- what is the value of AKT_Node?
Primary Objects.Node.Copy Key N:
- so yes, you can get the brand key, if you have the node key.
Interestingly, it looks like the order codes for getting key N are the same as for "get key" from a process key, except that you get the key info field as well as the key.
Primary Objects.Node.Swap Key N:
- "the process key names the same process" --- what process key?
Primary Objects.Node.Make Address Space Key:
- at last we find out: request format "R1" means "a full 32-bit word
encoding a 16-bit key info field". [No, it means "in register 1."]
- so if we make a request on a sense key ("sensory" or "sense"?) with a
request key info of 0, do we get RC_NoAccess or do the attributes get ORed? The spec here seems to imply both!
Primary Objects.Node.Compare Key:
- ah, so you don't actually need KEYBITS to compute the graph of the
nodes you have (non-sensory) access to. You can use this (at the cost of an O(N^2) run time).
- is an address space key a kind of node key? This seems to imply so,
but "address space" was not on the list of node key attributes.
- why is this operation not permitted for sensory or fetch keys? And
what's a fetch key, anyway?
Primary Objects.Node.Zero Node:
- what's the numerical value of "RC_Process_Returnee"? And what's the
deal with "the process key" being mentioned all over the place?
Primary Objects.Node.Key Data:
- is the "key data field" the same as the "key info field"? The
description says that the reply is a byte, not a 16-bit value, so I guess not. Do all keys have both fields?
Primary Objects.Node.Write Number to Slot N:
- aha, so a number key holds a 96-bit number. That must mean that keys
are bigger than 96 bits. [This is contradicted by Primary Objects.Number.]
- oh, so numbers are 80 bits, not 96, huh?
- what are the numerical values of AKT_Page and AKT_RoPage?
- so the elaborate scheduling system described in Concepts.Scheduling
doesn't exist yet?
- what's with the weird capitalization in the name?
Primary Objects.Address Space:
- does "up to 16" mean "up to 32"?
- should this be marked [TCB]? This is sort of like the One Ring.
- should this be a closely held key?
- it's probably reasonable to make this key closely held, but is it
really reasonable to say that exposing the physical location of objects on disk compromises the security of the system? If someone can get raw read requests to the disk, they can find out where objects live without needing KeyBits, and if they can't, the physical locations of things won't help them.
- 16 bytes --- does that mean that keys are 16 bytes long?
- is "closely restricted" the same as "closely held"? Why should the
ability to fabricate processes from nodes be closely held?
- is there a symbolic AKT_* constant for 0x100000A? Is it really
0x0100000A, as it's written, or 0x1000000A?
- AHA! "gate key" is defined at last. Start, resume, and fault keys
are "gate keys".
- here "key data" is defined as being 16 bits.
- link is called PhysRange
- now I know what a "logappend key" is.
- it's empty, but returner is described elsewhere
Kernel Objects.Schedule Creator:
- what's the numerical value of AKT_SchedCre?
- why does system restart make Sleep return early?
- spelling: "calendarr" for "calendar", "it's" for "its"
- are there no block devices? Or are those only for disks excluded
from the single-level store?
Device Objects.Ethernet III Driver:
- this should probably be closely held, or even in the TCB, for most systems
OK, I'm down at "standard processes", but I think I'm going to go to bed now. links tells me this section totals 91 screenfuls.
-- <firstname.lastname@example.org> Kragen Sitaker <http://www.pobox.com/~kragen/> The Internet stock bubble didn't burst on 1999-11-08. Hurrah! <URL:http://www.pobox.com/~kragen/bubble.html> The power didn't go out on 2000-01-01 either. :)