Re: Progress on AdaOS

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

> Yes, I must go through the kernel.

OK, then capabilities will do the trick for you.
 
> No queues and no scheduling.

Not sure what kind of "queue" you're talking about, but OK. And the lack
of scheduling is possible with any non-blocking system call.
 
> >Yeah. As an aside, I thought of doing this under CP/M about 20 years
> >ago. Never got around to it, tho. :-)
> 
> That guy claimed that it is possible, efficient and _made_. Maybe he
> meant some special hardware, or?

Oh, I'm sure there's hardware to do it in some CPU architecture. It was
just easy to hang hardware off a 8080 that would do the same thing, is
all. I don't even remember why I wanted to do it.
 
> >If you're trapping to the kernel to change memory protection in order to
> >do your call, I'm not sure what the efficiency benefits are between
> >doing that in one "process" or in two, especially if the two processes
> >can share memory to pass parameters and such.
> 
> In general same as with rendezvous and protected objects. Ada
> Rationale explains it excelently.

Errr, well, not really. You're assuming the rendezvous does an argument
marshalling via streams, yes, at least for the distributed case? I think
the rendezvous is probably slow because of the context switches between
the different threads, but I'm not going to profess to know the details
of what an Ada compiler generates. :-)
 
> >Then you need to put it in a different process, if your definition of
> >"process" is "all the code that can get to the same memory areas". If
> >that's not your definition, then you need to define clearly what you
> >mean by a "process". :-)
> 
> To me process is mainly a subject of scheduling, like a task [maybe a
> set of tasks].

Usually, the difference between a "process" and a "task" is that a
process doesn't share memory with any other process. A "task" shares
memory with all the other tasks in the same process. However, now you've
moved away from the standard terminology, so saying "it's really the
same process, but with different memory access" means you need to define
precisely what you're talking about. :-)

> I would like to have something less-weighted and data
> oriented [vs. procedural processes]. Something that I would call
> *safe* object, sort of DLL, but more secure.

OK. Then what you're looking for can be done with capabilities, *if* you
have hardware to support them directly (like OO hardware might) or if
you want to have the kernel remapping memory permissions.
 
> >Yes, of course they do. Many capabilities can be served by the same
> >object. A file could have a read capability, a write capability, and a
> >delete capability. If you look at the file server as the "object", then
> >all the files on that file server are access to different methods and
> >data members.
> 
> To me "read capability" is just a right to call the method "Read". 

It's not a question of "to you", really. It's a well-defined term. But
yes, knowing the value of a capability that hasn't been revoked
generally gives you rights to do those things for which you have the
capability. If the owner of the object is coded to be able to give you a
read-only capability, then you can do what you say.

> It
> should work so that each method and data member have a guard. A
> caller/user should "bribe" that guard (:-)). So the set of
> capabilities is potentially unlimited.

Correct. That's why you need it at some user level, rather than
kernel-enforced.
 
> Would be nice, but to be realistic I see no way other than a trap
> based implementation.

Yes, unless you're going to design your own CPU. On the other hand,
that's not as outrageous nowadays as it might have been 10 years ago.
:-) It certainly wouldn't promote a hobbyist AdaOS, I'll grant. :-)
 
> >or you need to have the compiler
> >generate code that enforces this and prevent users from disabling that
> >code in any way.
> 
> No, that would be a MS-DOS with an Ada compiler.

Err, sorry? No, you'd have a Burroughs B-series. They worked it by
having privledged (think "setuid" type priveledge) programs which were
the only ones allowed to write "executable" code, and those programs
were responsible for making sure you didn't do the Wrong Thing.
 
> >Or use the Hermes/NIL ideology, and let users only use high-level
> >languages that enforce pointer checking, array bounds checking, and etc.
> 
> IMO Any attempt to dictate user what he/she should use, would deem the
> system. They would surely like to have a Java VM, Visual Basic and who
> knows what else. Let them, but ensure that nothing they write in Basic
> may crash the system if they run that crap with normal privilegies.

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.

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