• Messages sorted by: [ date ][ thread ][ subject ][ author ] [ Next ]
• [ Previous ]

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:
Introduction.
1.1:
- 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.

1.2:
- 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.

1.3:
- 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?

1.4:
- 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.

• hmm, is a capage a node? ;) [no --- see Kernel Objects.Range]

2:
- 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.

2.1:
- 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.

Concepts.Constructor:
- a "client/service}" system?

• this seems like a good idea; it's very much like invoking your own copy of executables instead of connecting to a single long-running executable. You might want to mention high performance as well; web servers and other high-volume transaction processors will probably not create a new instance for each client.
• Hmm, I think "constructor" means "factory". It would be nice to have the word "factory" mentioned here for those of us who have read the KeyKOS stuff. I know it sounds old-fashioned, but "constructor" will sound old-fashioned, too, in 2015.
• what's a "distinguished" capability? (Some places this document uses "key", and other places it uses "capability".)
• discreet programs' faults certainly can propagate to other programs
  • it's just that you know which programs those are.
• ha, ha --- neologism! "netlet". :) And "missionism." :)

Concepts.Invocation:
- 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]

• where do you put the invocation type, anyway? Another register?
• what does "faulted" mean? That it's waiting for data to be paged in? [answered under Concepts.Keeper]
• so (3bii) will cause the invocation to happen again when the recipient's address space keeper pages in the missing data? (Do zero pages actually get copied into memory from disk? [according to Primary Objects.Page, no.]) I'm curious about this "stalled" thing.
• oh, a "gate key" is a key that lets you invoke a process. I remember now. [Defined in Kernel Objects.ProcessTool.]
• do steps 7 and 8 happen even if the key was a gate key?
• what is this "fault code"? Is this something a process can find out about itself?
• when can the recipient be faulted at the time of the invocation? Who is the recipient, anyway --- the new process the gate transferred the thread to, the invoker, what?
• what's a "kernely key"?
• this shared-service note --- does that mean that if I send a request to a shared service and then the area I'd allocated for the return gets paged out, then the request gets performed but I don't get to see the result?

Concepts.Keeper:
- 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.

• what's "OC"? ~0u presumably means "a 32-bit word of all ones"? [OC is "order code", the contents of SR0.]
• "program counter or address" --- presumably the address is always the program counter for execution faults, right?
• "296 bits" presumably means "2^96 bytes", right?
• why does the poor process keeper have to deal with address faults when there's no address keeper? How does the kernel know whether there's an address-space keeper or not --- does it try invoking the address-space keeper key and then retry with the process keeper if that returns "I'm a number key"?
• how do COW and demand-zero end up mapping to real pages on disk?
• presumably faults handled by a keeper aren't *always* transparent to the application --- the keeper may want to kill the application. How does it communicate to the kernel that it wants the application to continue?
• I take it that address space keepers are associated with address spaces, not with processs?

Concepts.Address Spaces:
- you can have pages of keys in the leaves of your address space?

• "ciel" I think means "ceil"; is "logndsz" "log to base ndsz"?
• "a 32-bit-address machine with 4096-byte pages and 32-slot nodes" --- does this apply to a 386?
• what happens to this lss value? Presumably it's #2 above; is it somehow encoded into the key? [Yes; see Primary Objects.Node.]

Concepts.Sensory Keys:
- 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.]

Concepts.Promptness:
- "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.

Concepts.Scheduling:
- 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

• for multimedia stuff in particular.
  - there's a "Send" invocation, which is what KeyKOS used to call EROS's
  "Fork". Does it mean "fork" here? Concepts.Invocation suggests that "send" means "invoke" generically.
  - I think the "Activate" explanation means "control flow continues with
  the *invoker* and the *invokee* is placed at the tail of the FIFO". The explanation that's there just repeats the "Send" explanation.
  - what's the "prime space bank"?
  
  • it sounds like the priority scheduler is a fixed-priority system like those commonly used in real-time systems, not a traditional timesharing scheduler. If someone wanted to implement a timesharing scheduler, would they be able to do so outside of the kernel?
  • why is the priority scheduling quantum (quanta is plural) so huge? 10 ms makes sense on a 16MHz 386, where it's tens of thousands of instructions, (which is why Linux uses it), but on modern machines, 10 ms is millions of instructions.

Concepts.Working Sets:
- oh, it's empty.

III, Primary Objects:
Primary Objects.Process:
- where is the information about which state a process is in stored?

• it still looks like there's no formal way to interrupt a process, but I suppose that you could take all its scheduled time away from it and modify its program counter if you had the process key, right?
• is this process root the same as the key registers node? [Doesn't look like it --- DR31 is the key registers node key.] Presumably all invocations of keys have to be of keys in the key registers node? [Yes, see below.]
• What are brand keys and symbol table space keys?
• DR9 says it has bytes 0-7 for PC and SP. Presumably that means keys are at least 64 bits long; are these the only registers that are saved when the process is not running, even when it's runnable? [No, see below.] Also, is DR9 a number key, I hope? [Yes, see under Primary Objects.Number.]
• it would be kind of nice to have more detailed information about the x86 implementation --- like, which key slots are used for extra registers.
• doesn't the size of user-mode register state depend on how big the register window stack is, which varies from SPARC to SPARC?
• do the comments here mean that EROS actually runs on all four architectures now?
• ah, so invocations of keys *must* be invocations of keys in the key registers node.
• it talks about "message send and receive control blocks"; does this mean that these values are all in core instead of in registers?
• it says "a value describing which four key registers are to be sent"; does this mean "four values", or do you always send four contiguous key registers? [Sort of both. See below.]
• it sounds like we have something like this: struct msg_snd_rcv_block { int type:2; int invokekey; int sk[4]; int rk[4]; char *datasend; int datasendlen; char *datarecv; int datarecvlen; }; which by my count is 13 int/char* words and two bits, so probably 14 int/char* words, or 56 bytes. It doesn't include the four sent and four received registers. (Actually, the length fields could share a word, but shouldn't.)
• this low-level stuff here feels really good.
• ah, so we cram sent and received key register indices into 5 bits each, thus "a value".
• "a faster implementation on register-starved architectures" --- hmm, like the 386? :)

1.4:
- 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"?

• here's that "OC" thing again. I'm starting to think it's an abbreviation for "order code", i.e. SR0. And now we have the first example of the object and operation format described in section 2 of the Introduction.
• why is "node" capitalized suddenly?
• what key is this "Check Alleged Key Type" defined on? The process key, which was last mentioned before section 1? [Looks like it.] Maybe the process root key or the key registers node key? Is the process root key the same thing as the process key?
• What's the definition of AKT_Process? It's not mentioned in section 1 of the introduction where AKT_Number and related stuff are mentioned.

Primary Objects.Process.Get Key:
- (0 <= N <= 32) --- what happens when N == 32?

• what's a component of the process? Is it a slot of the process root node? What is this stuff about the brand slot? [The clue is the brand slot comment; the result is RC_RequestError when "brand slot requested", which means we are indeed requesting a key from a slot of the process root. It's still a mystery why you shouldn't be able to request the key from the brand slot.] [See Kernel Objects.ProcessTool.]
• apparently the process key is different from the node key for the process root, because presumably with a node key, you could ask for slot 4, the brand key. So the process key must be a key to a kernel object other than the process root. Is it a stateful object? Is it another node? This seems implausible --- maybe it's really the process-root node key with some strange bit set? If so, then why is RC_Process_Malformed a possible return? Surely it makes sense to retrieve keys from any node, no matter how un-process-like, right?
• why is RC_Process_NoKeys a possible result? Are we trying to retrieve data from the process root or the process key registers node? (Likewise for Swap Key below.)
• presumably "specifying RK0 as the return key register" really means "KR0", not "RK0", right? RK0 is always the return key register, isn't it?

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?

• these get and set registers methods^H^H^H^H^H^H^Hoperations are cool. Much nicer than the Unix equivalents, I think. Why do they need to be kernel operations, though? Can't you just whack on the number keys in the process root node?
• the architecture identifiers are nybble-sex independent (palindromic) but not byte-sex independent. Byte-swapping 0x0b0000b0 gives you 0xb000000b, not itself. (It's not even bit-sex independent.)

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
Objects.ProcessTool.]
- 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?

Primary Objects.Node:
- provides the basic unit of storage for how many keys, did you say?

• primarily used to construct address space trees? Does this mean numerically, or by importance? :) I thought they were the force that bound the universe together . . .
• AHA! Node keys carry attributes, and here's the list. I take it these are *not* attributes that can be applied generally to all keys
  • *just node keys*. But "is a process root key" is not on the list. So process root keys are not node keys --- they're something else altogether. I thought the only stateful entities in the kernel were nodes and pages . . . ?
• the operation of making a sensory key is called "desensitizing"? Shouldn't it be "sensitizing"?
• ah, key info is 16 bits! And there's a reserved field for the lss, except that it's called the BLSS, which I'm not at all certain is the same thing, and which isn't explained here at all. (Oh, yes, it explains that it is the same thing: "biased log segment size".)

Primary Objects.Node.Check Alleged Key Type:
- what is the value of AKT_Node?

• ah, neat --- you can tell if a node key is a sensory key.

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.]

Primary Objects.Number:
- oh, so numbers are 80 bits, not 96, huh?

• Aha, number keys *are* used to store register values. (It says "Numbers keys", but I think it means "Number keys".)
• and at last the "null key" is defined.
• the invocation page merely said that invalid keys are turned into number keys. According to this, invalid keys are turned into null keys, specifically. (Also, according to the invocation page, the replacement happens when the key is invoked; according to this page, it happens when the object is destroyed. Maybe I'm conflating two different things, like rescinded keys and keys to dead objects.)
• actually, it says still more confusing things about rescinded and dead keys.

Primary Objects.Page:
- what are the numerical values of AKT_Page and AKT_RoPage?

• do you have to put a page into an address space to read and write data to and from it, or is there a corresponding key invocation?
• is Clone Page more efficient than the corresponding straightforward operation, e.g. by doing copy-on-write?

Primary Objects.SchedClass:
- 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"?

• "most enclosing callable keeper" is an interesting mechanisms. I can't quite see how to implement various policies within it; why is it better than "least enclosing callable keeper", which seems less restrictive? Won't "most enclosing callable keeper" end up always mapping to the same keeper --- the one for the root of the address space? Or is that intended and desirable?
• does "reflected" mean "forwarded"?
• hmm, this address space structure shows some signs of feeping creaturism.
• does "the blss value of a red address space resides in the format key" mean to say "black" rather than "red"?
• What's a "working set"?
• you refer to the "supervisor". Is this the same as the "kernel"?
• what are the numerical values of AKT_MalformedRedSeg, AKT_Space, AKT_FreshSeg, and AKT_VcskSeg? Why is "Virtual Copy Address Space" abbreviated as "VCSK"? Is an address space key a node key, and is AKT_Space the same as AKT_Node?

Kernel Objects.DeviceCreator:
- should this be marked [TCB]? This is sort of like the One Ring.

• is a serial port or a console a block device or a network device? Or is it not a device at all?
• what's a "unit key"?
• what's a "logappend key", and what does it have to do with the DeviceCreator and device keys? [apparently it's another kernel object; it is completely irrelevant to DeviceCreator]

Kernel Objects.Discrim:
- should this be a closely held key?

• is a "schedule key" the same as a "SchedClass key"?
• is "discrete" supposed to be "discreet"?
• is a "segment key" the same as an "address space key"? [Yes; see Kernel Objects.ProcessTool.]
• isn't a "read-only, no-call address-space key" a kind of sense key?
• what's a "data key"?

Kernel Objects.KeyBits:
- 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?

• are there cases where we would want to hand Discrim but not KeyBits to a process? If not, why does Discrim need to be able to compare keys?
• does KeyBits not support KT?
• what version of KeyBits is documented here? i.e. what is the first word of its result?

Kernel Objects.ProcessTool:
- 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.

• now it becomes clear why you don't want to hand out brand keys: you want process creators to be able to tell whether a process is their own, but not whose it is if it's somebody else's; and you don't want them to be able to forge someone else's brand.
• here's the "segment" thing again. It looks like a segment *is* an address space.

Kernel Objects.Range:
- link is called PhysRange

• this key should probably be in the TCB because it is not rescindable
• what's the numeric value of AKT_Range?
• AHA! Capability pages are NOT nodes. (Are capability pages the same as capages? I assume so.)
• now we have R1, R2, and R3; does that mean return registers 1, 2, and 3? It must.
• is a "strong key" a key that is not a sensory key?
• why does "Rescind" require a read-write key? Right there in the documentation it says you don't need one. Is it more convenient to require it?
• what's a "frame"? Is it the same thing as a "page"? Does this mean you can turn pages of data into pages of keys and vice versa?
• what does it mean for an object to be "mounted"? Does "wait" mean "block the machine" or "yield the processor"?
• it looks like capability pages are not the same as nodes, and can't even exist in the same page (so capability pages aren't made of nodes or vice versa). So what are capability pages and what are they used for?

Kernel Objects.LogAppend:
- now I know what a "logappend key" is.

• isn't KT+1 "number key"? Isn't KT+2 "unknown request"? How can you answer "unknown order code" if the order code is 1, which means "Append String to Log"?
• there are two links to Range from the Kernel Objects page
• there is a real PhysRange page, with no link to it

Kernel Objects.Returner:
- it's empty, but returner is described elsewhere

Kernel Objects.Schedule Creator:
- what's the numerical value of AKT_SchedCre?

Kernel Objects.Sleep:
- why does system restart make Sleep return early?

• the description for "Sleep for N milliseconds" makes Sleep sound like a deadline-scheduling real-time call. Is it?
• what good is "Sleep till N milliseconds since startup"?

Kernel Objects.TimeOfDay:
- spelling: "calendarr" for "calendar", "it's" for "its"

• it's probably appropriate to restrict the availability of this key in most environments.
• Get Hardware Time of Day is the only system call I've seen so far that's recognizably inferior to its Unix counterpart.
• there's that weird "KT+1 Unknown order code" thing again. What's that about?

Device Objects:
- 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

• what's up with the TX_INCORRECT_SRC_ADDR stuff? Shouldn't that be TxIncorrectSrcAddr?
• on Reset: the data format is ugly. And does "total frames received successfully" really overflow at 255?

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.

-- 
<kragen@pobox.com>       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.  :)

[ Next ]
• [ Previous ]