From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b95a522100671708 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Nick Roberts Newsgroups: comp.lang.ada Subject: Re: For the AdaOS folks Date: Tue, 4 Jan 2005 23:36:36 +0000 Message-ID: References: <1PTAd.1218$0y4.421@read1.cgocable.net> <1vemlj8wqr9ea$.qyecszhsmtqa$.dlg@40tude.net> <1b48kdfqsk3mw.7gajq12fsa82.dlg@40tude.net> <52fBd.42256$nV.1324414@news20.bellglobal.com> <33li96F422q0fU1@individual.net> <33qh7eF42pn2fU1@individual.net> Content-Type: text/plain; charset=us-ascii X-Trace: individual.net PoV0CMMvmPQ+hcInCG8wjARS+l8smsggbe9zclKow/+BG0Vq0= X-Orig-Path: not-for-mail User-Agent: Gemini/1.45d (Qt/3.3.2) (Windows-XP) Xref: g2news1.google.com comp.lang.ada:7448 Date: 2005-01-04T23:36:36+00:00 List-Id: "Luke A. Guest" 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