comp.lang.ada
 help / color / mirror / Atom feed
From: "Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk>
Subject: Re: For the AdaOS folks
Date: Sun, 02 Jan 2005 20:06:54 +0000
Date: 2005-01-02T20:06:54+00:00	[thread overview]
Message-ID: <pan.2005.01.02.20.06.53.326139@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> (raw)
In-Reply-To: 33qh7eF42pn2fU1@individual.net

On Sun, 02 Jan 2005 15:09:36 +0000, Marven Lee wrote:

> 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.

Wrong. They would be equivalent of a server/service in a microkernel that
supports memory protection. Each library would be mapped into the
application's address space when it is opened.

> 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.

Wrong. This is the only library that wouldn't be mapped into the
application's address space when opened, because it is always open.
Remember, exec.library is always available, you never have to open it, it
resides at address 0x00000004.

The exec.library is the "microkernel" of the AmigaOS, thus all of the
functions inside exec.library would become syscalls and it would already
be in memory, in kernel space, mapped into every running application's
address space, implicitly.

> 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.

Everything was done with message ports, any app/lib that needed to
implement any kind of messaging, could extend the exec's message type and
set up a port to send it to, see intuition.library for an example.

> 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 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.

> 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.

Which is essentially the way the AmigaOS worked.
 
>> 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.

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.

Luke.




  reply	other threads:[~2005-01-02 20:06 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-27  5:09 For the AdaOS folks Wes Groleau
2004-12-27 10:56 ` Florian Weimer
2004-12-27 12:50   ` Georg Bauhaus
2004-12-27 13:12     ` Florian Weimer
2004-12-28  1:18   ` Wes Groleau
2004-12-27 13:46 ` Adrien Plisson
2004-12-27 16:28   ` Georg Bauhaus
2004-12-28  6:19   ` Microkernels & Ada (Was for the AdaOS folks) Warren W. Gay VE3WWG
2004-12-28 12:02     ` Adrien Plisson
2004-12-28 15:28       ` Warren W. Gay VE3WWG
2004-12-30  1:19 ` For the AdaOS folks Nick Roberts
2004-12-30 13:58   ` Warren W. Gay VE3WWG
2004-12-30 15:27     ` Dmitry A. Kazakov
2004-12-30 16:30       ` Warren W. Gay VE3WWG
     [not found]         ` <otb8t09dkjh54e1k5s5ccn23ggkqk6ndui@4ax.com>
2004-12-30 19:06           ` OT: Mach Ports (For the AdaOS folks) Warren W. Gay VE3WWG
2004-12-31 10:03         ` For the AdaOS folks Dmitry A. Kazakov
2004-12-31 11:30           ` Warren W. Gay VE3WWG
2004-12-31 12:31             ` Dmitry A. Kazakov
2004-12-31 16:24               ` Warren W. Gay VE3WWG
2004-12-31 17:57                 ` Marven Lee
2004-12-31 18:40                   ` Warren W. Gay VE3WWG
2004-12-31 19:22                     ` Warren W. Gay VE3WWG
2005-01-02 15:09                     ` Marven Lee
2005-01-02 20:06                       ` Luke A. Guest [this message]
2005-01-03  3:13                         ` Warren W. Gay VE3WWG
2005-01-03  6:40                           ` Luke A. Guest
2005-01-03 10:30                             ` Marven Lee
2005-01-03 15:52                             ` Warren W. Gay VE3WWG
2005-01-03 16:48                           ` Ad Buijsen
2005-01-03 18:49                             ` Warren W. Gay VE3WWG
2005-01-03 13:43                         ` Marven Lee
2005-01-04 23:36                         ` Nick Roberts
2005-01-03 16:22                       ` Warren W. Gay VE3WWG
2005-01-04 23:16                       ` Nick Roberts
2005-01-05  3:48                         ` Warren W. Gay VE3WWG
2005-01-05 13:14                           ` Nick Roberts
2005-01-01 12:53                 ` Dmitry A. Kazakov
2005-01-02  0:31                   ` Warren W. Gay VE3WWG
2005-01-02 11:50                     ` Dmitry A. Kazakov
2005-01-02 22:04                       ` Warren W. Gay VE3WWG
2005-01-03 10:30                         ` Dmitry A. Kazakov
2005-01-03 16:36                           ` Warren W. Gay VE3WWG
2005-01-03 17:05                             ` Dmitry A. Kazakov
2005-01-03 19:01                               ` Warren W. Gay VE3WWG
2005-01-03 19:55                                 ` Dmitry A. Kazakov
2005-01-03 20:44                                   ` Warren W. Gay VE3WWG
2005-01-04  0:02                                     ` Randy Brukardt
2005-01-04 17:44                                       ` Warren W. Gay VE3WWG
2005-01-04 20:14                                         ` Nick Roberts
2005-01-04  9:59                                     ` Dmitry A. Kazakov
2005-01-04 18:00                                       ` Warren W. Gay VE3WWG
2005-01-04 19:07                                         ` Dmitry A. Kazakov
2005-01-04 19:57                                           ` Warren W. Gay VE3WWG
2005-01-05  0:02                                             ` Nick Roberts
2005-01-05  4:37                                               ` Warren W. Gay VE3WWG
2005-01-05 18:54                                                 ` Nick Roberts
2005-01-05 20:04                                                   ` Warren W. Gay VE3WWG
2005-01-06  0:32                                                     ` Nick Roberts
2005-01-06  1:29                                                   ` Wes Groleau
2005-01-06 11:03                                                     ` Dmitry A. Kazakov
2005-01-05  9:39                                             ` Dmitry A. Kazakov
2005-01-05 11:20                                               ` Warren W. Gay VE3WWG
2005-01-05 12:18                                                 ` Dmitry A. Kazakov
2005-01-05 14:39                                                   ` Warren W. Gay VE3WWG
2005-01-05 17:16                                                     ` zest_fien
2005-01-05 19:44                                                       ` Larry Kilgallen
2005-01-04 20:09           ` Nick Roberts
2005-01-05 10:19             ` Dmitry A. Kazakov
2005-01-05 18:33               ` Nick Roberts
2005-01-05 20:15                 ` Dmitry A. Kazakov
2004-12-31 18:47     ` Nick Roberts
2004-12-31 20:36       ` Warren W. Gay VE3WWG
2005-01-04 18:22         ` Nick Roberts
2005-01-05  5:12           ` Warren W. Gay VE3WWG
2005-01-05 18:02             ` Nick Roberts
2005-01-05 19:55               ` Warren W. Gay VE3WWG
2005-01-06  0:57                 ` Nick Roberts
2005-01-06  2:34                   ` Warren W. Gay VE3WWG
  -- strict thread matches above, loose matches on Subject: below --
2005-01-05 12:14 Mike Brenner
2005-01-05 18:04 ` Warren W. Gay VE3WWG
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox