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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-08 04:59:03 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!145.254.34.1!not-for-mail From: dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) Newsgroups: comp.lang.ada Subject: Re: Progress on AdaOS Date: Sat, 08 Sep 2001 12:02:06 GMT Message-ID: <3b99f79e.751695@news.cis.dfn.de> References: <3b95d429.592218@news.cis.dfn.de> <3B9654AE.CD4382ED@san.rr.com> <3b9768b6.1671036@news.cis.dfn.de> <3B97A5C7.3ED71528@san.rr.com> <3b9876e0.334859@news.cis.dfn.de> <3B98EEA2.179DD2A1@san.rr.com> NNTP-Posting-Host: 145.254.34.1 X-Trace: fu-berlin.de 999950341 7015519 145.254.34.1 (16 [77047]) X-Newsreader: Forte Free Agent 1.21/32.243 Xref: archiver1.google.com comp.lang.ada:12929 Date: 2001-09-08T12:02:06+00:00 List-Id: On Fri, 07 Sep 2001 15:58:30 GMT, Darren New wrote: >> If there is "a process that supplies a service", then it is another >> process, i.e. the method is executed on another context. > >I'm not sure how you would enforce any sort of access control in the >case of only having one context, actually. Well there should be several contexts of one process. For instance, let an application owns a "safe" object. It is safe in the sense that its data cannot be accessed otherwise than through the object's methods. To enforce this the corresponding memory pages should be normally inacessible for [read/]write. However when an object's method is called, there should be a context switch upon the call that would make the memory pages accessible for read/write. Upon return the context is switched back. I very like the idea, someone mentioned in a parallel thread, that the access rights can be made dependant on the page the PC points to. >> This is >> another case and a heavy weighted one. It would be very inefficient to >> have a separate process for every object. > >It doesn't need to be a separate process for every object. Indeed, in >Ameoba (Tannenbaum's OS), all the files are managed by one process. It is no matter one or many. It is like the difference between rendezvous and protected objects. You simply need both of them because rendezvous are inherently slow when compared with protected objects and yet not all necessary things can be made using solely protected objects. >You have a capability for each file, a capability for each server, a >capability for each directory, a capability for each process (so you can >kill it, debug it, etc), and so on. It is OK to me. >You don't have a capability for each array or tagged object, for >example, because you're not trying to protect them from yourself. Yes, but there are exceptions. Consider an object OpenKeyPair given to an application. The application is allowed to use its public methods (Code/Sign/Encode), but it cannot read its data, create a copy of it or pass it to another application. I have nothing against capacities if they allow to have access rights to object's methods and members dependent on the access level to the object itself. [Of course only "safe" objects are considered.] >> This will also exclude >> passive objects [= Ada protected objects] which have no task >> associated with. > >I think if you have the protected object in your data space, there's not >much point in enforcing an administrative limitation on who can get to >it. On the other hand, if your hardware supports capabilities directly, >then there's no problem with doing this. IMO it is very important to have *safe* objects living in the process space, because then a lot of things could be made within the process time quant, which otherwise would be served by some driver, ACP etc, with a catastrophic impact on real-time issues. >Think of a capability as vaguely similar to a trap instruction, perhaps. >You're granted a capability by the OS putting the address of the routine >to call into the interrupt vectors where you can get to it with a system >trap. The OS then checks that your arguments are legal. Same thing. Agree. It is how it could be implemented in a machine of usual achitecture. Maybe sometimes CPUs will support type tags, then... [at least 15 years old idea] (:-)) Regards, Dmitry Kazakov