🚀 go-pugleaf

In article <2582@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes:
>This started out as a response to a message about message passing, and
>I think it's worth kicking around for a while:
>
>Here's my solution.
>
>	(a) MMAP the same for kernel and user processes.
>	(b) Drivers, etc... run at TRANSFER privilege (== kernel or supervisor)
>	(c) MEMF_PRIVATE is write-protected. MEMF_PUBLIC isn't.
>	(d) There is a system call to raise you to TRANSFER privilege.

	Exactly as I had deduced.

>First thing to note... drivers already do a copy in the Amiga because (1)
>the system calls don't require block alignment, and (2) the driver uses the
>blitter to generate and decode MFM, so data outside MEMF_CHIP has to be copied
>anyway.

	There are a lot of other drivers, not all require that.

>If you want another program to get at your data, you make it MEMF_PUBLIC.
>Otherwise, it's MEMF_PRIVATE. Drivers can get to MEMF_PRIVATE, but only
>because there are programs out there that pass statically allocated data
>to drivers. New programs won't do this, we hope.

	Here's the killer:  the default of MEMF_PRIVATE will kill 
innumerable programs, including most of the current RKM example programs.
There may have to be a (NEWSTYLE/OLDSTYLE) flag on a pre-process basis 
to set the default for the process.

	Also, due to MMU constraints, big mods to AllocMem will be needed.
Each program will need a private pool of private mem, to avoid frequent
re-maps and granularity problems.  Public mem would be one big pool.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup