Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!bpa!cbmvax!valentin
From: valentin@cbmvax.commodore.com (Valentin Pepelea)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Memory Protection!
Message-ID: <13693@cbmvax.commodore.com>
Date: 8 Aug 90 04:01:47 GMT
References: <1145.26bd4989@waikato.ac.nz>
Reply-To: valentin@cbmvax (Valentin Pepelea)
Organization: Commodore, West Chester, PA
Lines: 59

In article <1145.26bd4989@waikato.ac.nz> hamish@waikato.ac.nz writes:
>
>    1 resource tracking will make things slower.
>       Well ARP doesn't seem to be suffering too much does it? And that
>       has had resource tracking since day one. IMNSHO it would be a better
>       OS if an errant program could be cleaned up after it was killed off.

The problem is not that resource tracking has not been implemented, but rather
that resource tracking has not been promoted as a concept. Therefore we have
software today that would barf all over resource tracking enhancements.

For example, how about a program that allocates some memory for a message, sends
the message to another task and then quits. The other task then receives the
message and frees its memory when it is done with it.

Now if we implement resource tracking which frees all the memory of a program
when the program exits, then the memory of the message will be freed also.
When the second task then tries to access that message... Poof!

The same problem arises with opened windows, message ports, etc...

>    2 People don't use MEMF_PUBLIC for messages.
>       Well if we make all unallocated memory to be non-readable and 
>       non-writable that would probably catch a few errant pointers.

Well, some has already suggest that we write a trap handler which reports
on the serial port at 9600 illegal accesses to free memroy. Consider it
done. :-)

Oh, and you're right. It does catch a large number of errant tasks. I call this
trap handler my Guardian-Angel; I don't leave the computer without it. :-)

>	The code hunks could be make read-only for all tasks and if people are
>       using a code hunk to hide a message port (ie for data) then they
>       deserve to have their program curl up and die on them.

Unfortunately this is too common. Much to common. I don't know of anybody that
does not do this. (they have not advertized) I do this all the time.

>    3 Write protecting ram based libraries and bottom of memory.
>       Well I don't remember any good reason for not write protecting
>       these.

Both the ROM and bottom of memory (page zero) are write protected. Actually
page zero is also read protected. A special check is made to verify whether
location 4 (pointer to address of ExecBase) is being read.

>       After all who needs to write to libraries apart from routines
>       (supposedly through the OS) that patch them.

If it is a disk-based library, then chances are it will have R/W data embedded
in code hunks. Sorry.

Valentin
-- 
The Goddess of democracy? "The tyrants     Name:    Valentin Pepelea
may distroy a statue,  but they cannot     Phone:   (215) 431-9327
kill a god."                               UseNet:  cbmvax!valentin@uunet.uu.net
             - Ancient Chinese Proverb     Claimer: I not Commodore spokesman be