Re: Progress on AdaOS

[Darren New <dnew@san.rr.com>]

> I many OSes a process may have several tasks [threads]. Why not to
> have several memory mappings as well?

Nothing wrong with that. It's just not what the word "process"
classically means.
 
> >Correct. That's why you need it at some user level, rather than
> >kernel-enforced.
> 
> Why not? Could a capacity be represented by a tagged type, and so that
> dispatch [sometimes] happens on the kernel context?

Well, if I have a tagged type that dispatches to the kernel, and there's
three inherited procedures, and you only want the holder of the tagged
object to be able to dispatch to one of them, you're going to have
trouble. Maybe all three will dispatch to the kernel, and the kernel
will decide that two of them are erroneous and should raise
Capability_Error or something, but then that's a user-level check,
rather than a hardware check. The fact that the code is running with
kernel permissions doesn't change the fact that it's software doing the
checking, which is what I meant.

> >Yes. And you can do this by either using hardware protection, or using a
> >VB interpreter that doesn't let them run off the end of arrays. The
> >JavaVM (other than JNI etc) certainly doesn't need hardware support to
> >keep you from doing something nasty - that's the whole idea of the
> >sandbox.
> 
> What about hardware/software faults?

What about them? You're still going to have the kernel managing the
memory maps in your scheme, and if there's a fault in that software, you
still have a fault. You're still going to have programs like "login"
handling your permissions. It's going to take lots of development to
make it reliable. 

My point was that there are more ways to think about the problem than I
think have been considered. Certainly more solutions than have been
investigated here.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
    Those who work hard with few results always 
           value hard work over getting results.