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:16:45 +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 syetfcZN/YHuizt6rZXBKQiqAVW3LhuYmhtE0ibvwxTNUH0sE= X-Orig-Path: not-for-mail User-Agent: Gemini/1.45d (Qt/3.3.2) (Windows-XP) Xref: g2news1.google.com comp.lang.ada:7446 Date: 2005-01-04T23:16:45+00:00 List-Id: "Marven Lee" wrote: > > > You can end up with a microkernel that only handles cross-domain > > > calls. Everything else, including what you normally think a > > > microkernel should at least include, > > > > I'm glad you said "normally" here. ;-) > > > > > such as memory management, scheduling and IPC can be implemented > > > outside of the microkernel. > > > > Exokernel? > > No, I'd still call it a microkernel or perhaps a trampoline. Bachar has cross-domain calls (I think ;-) although I've called them 'IPC service calls', and describe them in terms of the client-server model. A process that provides a service (the server process) obtains a kernel resource called an 'IPC service', and publishes it somehow (how is a long story). A process that wants to use the service (the client process) obtains a kernel resource called a 'service key', whose target service is the required IPC service. The client then calls the service key to obtain the service. The server receives calls to its IPC service, performs the service, and returns. The (calling thread of the) client remains blocked until this is complete. > I like the way you can pass areas of memory between address spaces without > having to search for a suitable place to stick it in the destination > address space, they can use the same region of the address space in each > address space. This might also be useful when copying data through a > series of address spaces. I don't think having pointers meaning the same > thing in different address spaces is a benefit though, especially in > messages where a pointer could point outside a message without any error > checking. AdaOS provides multiple memory 'regions'. A process can map multiple regions into its address space at one time. Several processes can share a memory region by obtaining kernel resources called 'region keys', and using those keys to map the region. Again, a mechanism of publishing provides the means for processes to co-ordinate this. The idea is that one or more shared regions can be used to pass parameters between processes in accompaniment to IPC service calls. Because the regions for doing this are genuinely shared memory areas -- if the the client and server both reside on the same workstation -- there is no copying involved (although there may be marshalling on both sides, where the format of data is generally changed). However, the exact same IPC calls can be made trans-network, completely transparently to both client and server, by the insertion of 'agent' (proxy) processes: the client calls a client agent; the client agent communicates the call across the network to the server agent; the server agent calls the server; when the server finishes, the server agent communicates the reply to the client agent; the client agent returns the reply to the client. Distributed memory regions are used, so that pages of data get automatically pulled around the network as they are used by client and server. An asynchronous form of call is also supported (the client thread is not blocked, and there is no reply). This scheme is completely secure: no process can ever gain access to data it is not permitted to access (it is prevented from getting a region key), and no client can call a service it is not permitted to (it is prevented from getting a service key). -- Nick Roberts