OS design...

[Ray Dillinger]

On Sat, 17 Oct 1998, Francois-Rene Rideau wrote:

>>: Ray Dillinger, on lispos@math.gatech.edu
>
>> No, not routines per se, but a way of saying "such and such
>> service has been spawned as a process and is waiting for input
>> in QQQ format on port XXX."
>This is but a uselessly low-level special case for
>"we have an object named X, of type Q->S".
>If you hate types, understand "specification" instead.

What I'm talking about here is how programs establish and access
services, including but not limited to those services provided
by a typical operating system.  At the level of someone writing
code at a higher level than raw assembly (assembly language
without macros) accessing a service should look just like a
function call.  

>That's fine, if only the admission control can check security.
>In a low-level system, that's quite a costly feat.
>In a high-level system, it's just a very particular case
>of dynamic compilation.

Not quite. In any system, you have code you trust and code you
don't trust.  Dynamically compiling the code you don't trust
into the code you trust is one of many possible "Wrong Things". 
A user can punch raw hex values into any location in any file
his shell's credential allows him to write, including
executables, using a hex editor.  Yes, it's a dangerous thing,
but it is sometimes a useful thing.  If it is possible to
write code (even using a hex editor) that forces the operating
system to compromise itself (make hash of its process table,
allow a process to terminate without reclaiming the memory and
other resources allocated to it, become deadlocked, etc), then
there is an error in the operating system. If it is not possible
for a user to write her own compiler (which may contain errors) 
then you have placed handcuffs on the usefulness of your system. 

>I think it's a real bad idea to specify low-level details:

I think it's not possible to *implement* low-level details
without specifying them.  Right now my concern is what kind of
raw machine code my compiler should produce when a program
someone has written wants to access a service.  If you have an
answer that doesn't require specifying low-level details I'd
like to hear it.

>keep the interface as high-level as possible,

The interface that a programmer has to deal with (other than a
compiler writer or raw machine code programmer) *should* be as
high-level as possible, agreed.  But it can't be magic, because
"abracadabra" doesn't compile.  It has to be built out of
lower-level parts, all the way down to the bare wires.

>If I want a process to be waked up on a condition,
>what I want is this process to be waked up on that condition;
>what I want isn't lots of stupid low-level things to happen;
>hell, I don't remotely give a *shit* about those low-level things!
>The less I need to know about them, the happier I am.

You want to be waked up on that condition, but you don't want a
system that has some low-level structure for executing the
(possibly untrusted) code that computes that condition and
acting on the result? 

  Error: Call to undefined function "abracadabra" in line 666.

>If those things were "the only sensible thing to do",
>then the system ought to do them, and I needn't specify them;
>if those things weren't, then why overspecify,
>and prevent the implementer to use completely different techniques,
>that might better fit the completely different constraints of another day?

I *am* the implementor.  I have to implement things low-level
enough to run on hardware.  That's why I'm building low-level
structures and asking low-level questions.

>Fuck low-level systems! Translating high-level into low-level is
>the compiler's job, not the programmer's job. As a compiler-writer,
>I'm interested in it; as a programmer, I abhorre it.

High-level systems can't run without low-level definitions.
When you're living in a house you should never have to think
about the foundations.  But the foundations have to be there and
the people who build the house (in the case of an operating
system that would be us here on the LispOS list) have to think
about them hard enough to actually build them. 

				Ray