Re: For the AdaOS folks

[Nick Roberts <nick.roberts@acm.org>]

"Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> wrote:

> > > Correct. That's why a protected AmigaOS must support protection
> > > domains not only for processes but also for libraries. That's a
> > > generalization of the UNIX model. There you have protection domains
> > > for each process plus one protection domain for the kernel which is
> > > mainly a huge library. In AmigaOS every library would need its own
> > > protection domain and context switches must be as lightweight as
> > > possible.
> 
> I certainly wouldn't do it like that. On hardware that has an MMU (most
> these days), that would result in a very slow system due to the amount of
> context switches, this is why the libraries need to be mapped into the
> address space of the running app, i.e. shared between applications.

It is necessary to be able to take both approaches.

If you trust the code in a library never to deliberately (and to be unlikely
to accidentally) subvert the security of the data your own program could
have access to, you can map it into your address space, so that your calls
upon that code can be efficient (they do not have to cross any protection
boundary).

Otherwise, you must place some or all of the less-than-completely trusted
code in a separate protection space, so that it is prevented from accessing
data other than the data you explicitly permit to access. One popular way to
do this is to make the less-than-completely trusted code into a program that
executes as a 'server', and you, the 'client', make calls to it which do
transition a protection boundary.

Sometimes you need the efficiency (and you trust the code), sometimes you
need the protection (because you don't trust the code). So, both mechanisms
must be available.

> Single address space OSes are only useful if you have loads of memory and
> you're not using that many apps at any one time. So you need to be more
> careful with the sizes of apps. You will run out of memory, especially
> considering the size of apps these days.

Exactly why I've chosen a design, for the IA-32, that gives each process
(almost) the full 4 GiB.

-- 
Nick Roberts