Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

Memory protection tho

0 views

Skip to first unread message

DARKMAGI

unread,

Jul 17, 1995, 3:00:00 AM7/17/95

>
> Okay... Well, let's see... Assuming we'd be using some kind of paged
> memory system, we could just remap the pages. For example, process A
> wants to send a message to process B. All the OS would need to do is
> take the page of ram that A's message is in, and remap it into B's page
> table, while removing it from A's. In otherwords, A's address space is
> now smaller, and B's is bigger.
> How could this work? Well, the important thing is that you only remap
> the part of A's address space that you want to send, and leave the rest,
> so you must make sure that the only thing in that page is A's message to
> B, and nothing else that belongs to A. So, I was thinking perhaps add
> another TAG to AllocMem, something like NEWPAGE, which would force
> AllocMem to allocate memory starting a new page.
> You would give it a size as well, so, lets assume the pages are only
> 1024 bytes each, and you ask for 1800 bytes. No problem, it'll allocate
> 2 new pages for you. You could then write into these pages, and then
> call
> something like NewPutMsg() to send it off to B (which will only remap the
>
> page tables). I think Mach does something like this.
> You could also have another function called RemapPage(), that can take
> a pointer to another task, and remap any page you own to that other
> task. This way, you could open a window, and give it to another task.
> As for shared memory pools, well, that shouldn't be a problem
> either.... Since all pages will be identified with a given task, you
> could make a special ID for shared memory (say shared memory ID == 0).
> Therefore, you could allocate memory in your address space, write to it,
> and then stick it in shared memory, OR, to any other tasks address space.

You'd need to write a complete virtual memory system into the OS, so that each task
has it's own MMU table, and the exec core is the only part of the system running in
un-remaped memory. This would be a HELL of a rewrite, but would certainly add some
SERIOUS power to the OS. Done correctly, every task could have access to 4GB of
Code space and 4GB od Data space (assuming you had enough hard drive space to support
it <G>) I don't think you want to have a ponderous AddPage() and RemPage() method
(at least, not at the user level) though. Let AllocMem() do the work transparently,
so that you never need to know about it. You can let exec handle message passing
with existing structures. Part of the Message structure is SIZE, so you could pass
any arbitrary chunk of data to another task via a message port and let exec deal with
it. (either by remapping a piece of real memory from one space to the next or by copying
the data from one place to another.) Any way you slice it though, this would require
some SERIOUS overhauling of the OS (probably a total rewrite from scratch of the exec
code, at the very least!) Any volunteers? <G>

-Jeff
,,,
dark...@cris.com (o^o) Jeff Crystal (KB8RNQ)
________________________oOO_(_)_OOo____________________________

| AmiQWK 2.7 | UNREGISTERED EVALUATION COPY - SUPPORT THE SHAREWARE CONCEPT
... "Do you really want the answer? The ULTIMATE answer?" - Deep Thought

Michael Veroukis

unread,

Jul 18, 1995, 3:00:00 AM7/18/95

In article <3ucr4b$s...@warp.cris.com> Dark...@cris.com (DARKMAGI) writes:
>You'd need to write a complete virtual memory system into the OS, so that each task
>has it's own MMU table, and the exec core is the only part of the system running in
>un-remaped memory. This would be a HELL of a rewrite, but would certainly add some
>SERIOUS power to the OS. Done correctly, every task could have access to 4GB of

Well, VM and MP tend to work in the same way. Once you start using the MMU,
you start thinking of ram in terms of pages, not bytes :) However,
sure, this WOULD be a major re-write, but aren't we all expecting the
next Amiga OS to be on some RISC chip? Wouldn't that require a re-write
of Exec anyway? Wouldn't it be nice if the RISC AmigaOS had rock solid
memory protection, YET, could still run the older software through
emulation of some sort?
It's quite possible we'll never see a 680X0 AmigaOS with Memory protection.
Escom will probably hold off all the major OS changes for the RISC
implementation. Why introduce MP for the 680x0, which would probably
break half the existing software, if not more, and then introduce a RISC
OS, which would kill off the rest? :) Well, it might not be that bad,
but still, I don't think Escom is THAT rich.
....Unless they ditch the Risc Amiga idea all together.... I don't
wanna think about that though! :)

>Code space and 4GB od Data space (assuming you had enough hard drive space to support
>it <G>) I don't think you want to have a ponderous AddPage() and RemPage() method
>(at least, not at the user level) though. Let AllocMem() do the work transparently,
>so that you never need to know about it. You can let exec handle message passing
>with existing structures. Part of the Message structure is SIZE, so you could pass

Ofcourse, that's what I meant... Sorry if it wasn't clear. I was talking
both highlevel and low level at the same time :) So, you call
AllocMem(), and it would allocate pages, as it sees fit. You might have
to tell AllocMem to allocate memory starting at a new page, so the OS can
remap it easier.
However, there is one downside to this approach, and was pointed out a
few messages ago. On some MMUs, the minimum page size can be big. One
example given was the 040/060 MMU which has 4096 byte pages. If you have
only 256 messages in the system at one time, that'll use up a meg right
there. It's a big waste! (unless, all your messages happen to be 4096
bytes each ;). But, you can still get around this, but it starts to get
ugly. For small messages, you could copy the entire message to the other
task's memory (ofcouse, the OS would have to do this). On a RISC chip,
this might not be so bad. Not sure. It could still remap big messages
for speed.

One thing to remember is that MP is not free. Something will have to
be sacrificed. The other thing to remember is the day of the 68000 is
gone, and we can expect more from the modern CPUs. One other thing I may
point out is that VM would be a sinch to add once the MP is finished.
Kill two birds with one stone. What other features does a modern OS
require???

Anyways, that's my suggestion... I'm not really a hardware guy, so I'm
sure others know better then me. I kinda like this approach, but seem to
be the only one on this newsgroup with this point of view :)

0 new messages