OS design...

[Francois-Rene Rideau]

>>: Fare
>: Bear

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

Do you mean a foreign function interface to existing systems/programs,
or just a standard library for your system?
In the former case, you sure need to access low-level details,
but this is not much of a design issue,
since those details are already specified.
In the latter case, my advice was to stay as high-level as possible,
not specify *anything* about the low-level parts,
as far as the user/programmer is concerned,
and just go implement the compiler.


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

Wrong. Just don't execute code you don't trust!
That's also the most basic protection against trojans, btw.
Of course, trust can be dynamically built, be it through
careful runtime-checks, static typechecking, proof-carrying code, etc.
The stupidest (and ultimate) way being "I trust it because superuser told me".


> Dynamically compiling the code you don't trust
> into the code you trust is one of many possible "Wrong Things".

Just refuse code you don't trust, or require that trust be built.
Oh, certainly, a wrapper using "paranoid black box protection"
might be a (gross) way to build trust;
still, leave the low-level details of the wrapper to the wrapper implementor,
and concentrate on the high-level interface.


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

If he can, then your OS is broken by design.
See a previous message on the list where someone (Kragen?) explains
how it the OS can inductively maintain a per-"file" bit (or more info)
so that only trusted binaries (e.g. produced by a trusted compiler)
may be executed.


> Yes, it's a dangerous thing, but it is sometimes a useful thing.

Certainly, the superuser may do that.
Also, users may want to do that, inside a trust-building protection box.


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

Uh? I may well allow to write compilers, but require them
to either use trusted low-level sandboxes (as under Unix),
or a trusted backend. Most Unix language implementations compile thru C.
I see no problem with requiring most (i.e. all non-trusted) LispOS
language implementations to compile thru Lisp.


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

Oh, sure, if that's what you mean.
But then, stop worrying about silly low-level MMU-based message passing.
Rather, specify your OS in terms of LAMBDAs, and worry implementing
LAMBDAs efficiently (including calling conventions, garbage collection, etc).
One advantage of this approach is that if you find a completely different way
to implement LAMBDAs, that work much faster under different hardware
constraints, then you may reuse the rest of the system unchanged.


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

Just the same as when a program wants to access any LAMBDA abstraction!!!
Services *ARE* LAMBDA abstractions!


> If you have an answer that doesn't require specifying
> low-level details I'd like to hear it.

Oh, if you're asking "how am I going to implement LAMBDAs?",
then I may point you to the large existing literature on the subject,
and/or to available implementations.
For instance, one may to do would be to have LAMBDA invocation be just
standard C-like function call (with additional register use);
when needed, the function body would be dynamically generated
to push its closed environment and call real body, when needed.
But that's just one way among many others.
This supposes a stack; you may implement in the normal "C" way,
using the MMU when available to detect overflow and take appropriate measures
(extend the stack; "close" it and start a new one; whatever you like).

For efficiency purposes, your compiler may manage several different forms
of low-level lambdas, with different calling conventions
(separating "simple" lambdas from elaborate closures;
distinguishing real-time/real-space lambdas from usual ones; etc).
That's best managed automatically, but you may allow for user-declarations
for that. Interrupt routines would have to be real-time.


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

That I understand. My point is: the low-level parts are just
"normal" compiler output, not anything special about "system" services.
If you explicitly want to discuss compiler details, ok.
If you want to invent special "system" conventions, it's wrongheaded.


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

Sure. And the foundation is: the compiler. Not anything in the "kernel".
Choose an existing compiler, or implement a new one; calling conventions
for "system services" will follow automatically from that choice.

## Faré | VN: Уng-Vû Bân   | Join the TUNES project!  http://www.tunes.org/ ##
## FR: François-René Rideau |    TUNES is a Useful, Not Expedient System     ##
## Reflection&Cybernethics  | Project for a Free Reflective Computing System ##
There is no meaning without words, no shape without matter,
no soul without body.