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!news1.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Marven Lee" Newsgroups: comp.lang.ada Subject: Re: For the AdaOS folks Date: Sun, 2 Jan 2005 15:09:36 -0000 Message-ID: <33qh7eF42pn2fU1@individual.net> 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> X-Trace: individual.net +8+jPdUNi9Sr3RY98N2ijAf+SrT0+CTlso6GOToTDr+e0RNiWc X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Original Xref: g2news1.google.com comp.lang.ada:7388 Date: 2005-01-02T15:09:36+00:00 List-Id: Warren W. Gay VE3WWG wrote: > Marven Lee wrote: >> In Mach it's called "migrating threads". > > Yes, I've seen references to this in the Mach > literature. Yes, and from your other post you've already found the paper on migrating threads in Mach. http://www.brynosaurus.com/pub.html It is interesting to note that he wrote some libraries and apps on AmigaOS. I think he works for Microsoft now. >> 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. It would be a bit like Ingo Molnar's 4GB kernel / 4GB user patch for Linux. http://lkml.org/lkml/2003/7/8/246 This moved the kernel from the top 1GB of every process into a 4GB address space of its own. a 16MB trampoline (microkernel) exists at the top of every address space to transfer syscalls and interrupts into the address space that the Linux kernel resides in. In some ways this is similar to a single server Linux personality running on a microkernel like L4Linux. I think the difference between the trampoline and L4Linux can be summed up as L4 uses an active object model and the trampoline/migrating threads uses a passive object model. I'm not sure if or why the 4G4G in Linux needs 16MB, it can be done in less than a page of code and a few bytes of data. The trampoline should take up something in the region of 8KB of the address space. You could replace Linux with Mach as the personality. Yes, it sounds a bit wierd having Mach run on top of a microkernel or trampoline. Although Mach would be running as a single server personality this doesn't stop multiple servers existing, they just have to make cross-domain calls into the Mach personality to make use of Mach's IPC. It is single server only from the point of view of cross-domain calls through the trampoline microkernel. So you can think of this trampoline/microkernel as a fancy syscall redirection mechanism that moves a kernel from kernel-mode in all address spaces to its own address space. The trampoline copies small messages in registers, if you want to copy more then you have to change functions in the personality such as copy_to_user() and copy_from_user() to map pages from the application process into the personality and copy the data from there. By using a more sophisticated trampoline that keeps track of what protection domains a thread has permission to migrate to you can have a multiserver cross-domain call mechanism. The trampoline would require more storage space than the simple single server approach. I've dug up an old thread from alt.os.development where KVP describes a single server trampoline and I follow up with a rough idea of how to implement a trampoline-microkernel that supports multiple servers. http://tinyurl.com/6gb5b That was an old posting of mine and I'd probably change the "activation" structure around a bit. I'd more likely use array indices to reference other activations instead of pointers. I'd also change some of the needed system calls as well. Onto AmigaOS. Let me make this clear from the outset to any Amigans reading that what I'm about to write below isn't about how to add memory protection to AmigaOS, it's only about how the structure of AmigaOS relates to microkernels that make use of cross-domain calls / migrating threads. I always think of migrating threads in terms of AmigaOS. AmigaOS didn't have any protection and divided everything into shared libraries. But the libraries weren't like those in other operating systems, they were more like the subsystems of a kernel. Ideally they should have been placed in their own address spaces/protection domains and a cross-domain call should have been used to access them. The core library of AmigaOS, exec.library would become a server, just like Mach in the above single server example. All other libraries, including devices which are more or less libraries with their own thread would also become servers. It would be as if the a trampoline microkernel had replaced the library jump tables it used. In an earlier post in this thread Dennis Lee Bieber said everything was done with message ports, from my point of view I'd say everthing was done with library calls. After all the message passing was done by library calls to exec.library. In effect what they should be is, "Protected Shared Libraries." * I had wondered if anyone in the Amiga community had come up with similar ideas and found this in a 1997 newsgroup posting entitled "p-OS & Multiprocessing"... Michael van Elst wrote: > Jeroen T. Vermeulen wrote: >> One major problem is that the Amiga's shared libraries act as >> OOP-style objects, matching responsibilities to context much more >> elegantly than other OSs do (where process ID is everything). A >> process conceptually switches to a different protection domain when >> it calls a library function. > > 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 also like the way each thread in AmigaOS has access to exec.library. Each thread could call the exec.library functions OpenLibrary() and CloseLibrary() to load a library into memory and obtain a handle to access it. A similar way could be used for loading modules in a system that uses cross-domain calls/migrating threads except that it would need to create a stack in a server for a thread to use when it has called into the server. These "protected shared libraries" (PSLs from now on) needn't be global to the entire system. You could have global PSLs for the memory manager, the filesystem, networking and GUI. Per- user PSLs for things like a clipboard and desktop. Finally you could have per application private PSLs so as to decompose an application into a number of PSLs. > I've never been too keen on the single address space systems. 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. Now for some suggested reading... "High Performance Cross Address Space Communication" and "Lightweight Remote Procedure Call" by B.Bershad. One of the older papers that other papers cite. "Evolving Mach 3.0 to a Migrating Thread Model" and "Microkernels Should Support Passive Objects" by B.Ford & J.Lepreau. The second one puts forward some reasons why microkernels should use migrating threads. Sun's "Spring nucleus, A Microkernel for Objects" by G. Hamilton. They took the idea of Doors from Spring and later added them to Solaris. The "Pebble Operating System" http://www.bell-labs.com/project/pebble/ has a few papers, "The Pebble Component-Based Operating System" is the main one. "The Mungi Single-Address-Space Operating System" by G.Heiser. Although I think it runs on top of L4 it has a "protected procedure call" mechanism called PDX. There is also the Grasshopper kernel but I'm not sure what the main research papers on it are called. * "Protected Shared Libraries" by A.Banerju and D.L. Cohn. Then there are kernel-less systems that have some similarities to cross-domain calls. "Anonymous RPC" by C.Yarvin et al. Imagine the Amiga's shared libraries randomly scattered around a 64-bit address space. Imagine also that the Amiga library jump tables are execute-only and not readable, and that it was running on a RISC chip with instruction-alignment constraints. Then you've got a idea of what "Anonymous RPC" and probablistic memory protection is about. "Implementing Operating Systems without Kernels" and "Efficient Cross-domain Mechanisms for Building Kernel-less Operating Systems" by D.Probert and J.Bruno. I read it some time ago, I think it is more or less about the trampoline/microkernel being implemented in hardware. Marv