peter@sugar.uu.net (Peter da Silva) (09/01/88)
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. 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. 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. There's no extra danger for (d)... after all, programs can already inhibit context switching and even interrupts. Make Disable() and Enable() do this automatically, so: You can have some global flag in preferences that determines whether copper lists etc. are secure or not. If Disable() and Enable() move you into and out of TRANSFER priority, then this should not be necessary for most programs. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
jesup@cbmvax.UUCP (Randell Jesup) (09/01/88)
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
peter@sugar.uu.net (Peter da Silva) (09/02/88)
In article <4625@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > 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. Actually, the best way to do this would be to add a MEMF_PUBLIC flag to each of the hunks, like the current MEMF_CHIP flag. Programs that break can be fixhunked. Then add a '+P' flag to the manx linker to match the current '+C' flag. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/03/88)
: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. No, copying is not required. For instance, the FFS will pass along data pointers to whichever trackdisk device it is mounted on whenever possible, And MY microbotics StarDrive does NOT copy data to any buffers when reading/ writing but transfers it from the request to the SCSI bus directly. (In fact, everybody's mother except the floppy trackdisk device does this). That isn't to say copying is never used.... it is used quite a bit in the OS, but it isn't used 100% of the time. -Matt
jesup@cbmvax.UUCP (Randell Jesup) (09/03/88)
In article <2591@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >In article <4625@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: >> 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. > >Actually, the best way to do this would be to add a MEMF_PUBLIC flag to >each of the hunks, like the current MEMF_CHIP flag. Programs that break >can be fixhunked. I wasn't talking about load files, but AllocMem calls. Load files are easy. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
haitex@pnet01.cts.com (Wade Bickel) (09/04/88)
jesup@cbmvax.UUCP (Randell Jesup) writes: > 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. > Is it possible to define a new mem class? MEMF_LOCAL for example? Then we could treat MEMF_PRIVATE as MEMF_PUBLIC and future programs would be safe. Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM Opionions expressed are mine, and not necessarily those of my employer.
peter@sugar.uu.net (Peter da Silva) (09/08/88)
In article <4642@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > In article <2591@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > >Actually, the best way to do this would be to add a MEMF_PUBLIC flag to > >each of the hunks, like the current MEMF_CHIP flag. Programs that break > >can be fixhunked. > I wasn't talking about load files, but AllocMem calls. Load files > are easy. Well, fixing the load files will take care of most of the RKM problems, which seem largely to be caused by programs using static data structures for PUBLIC purposes. I suppose some programs will still break, but not too many... -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
peter@sugar.uu.net (Peter da Silva) (09/09/88)
In article <8809021811.AA13386@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > :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. > No, copying is not required. For instance, the FFS will pass along > data pointers to whichever trackdisk device it is mounted on whenever possible, > And MY microbotics StarDrive does NOT copy data to any buffers when reading/ > writing but transfers it from the request to the SCSI bus directly. That takes care of problem 2. But the trackdisk.device or SCSI.device still has to take this nonaligned chunk of data and merge it with the actual blocks. Say you are doing a 512 byte write to a device with 1K blocks. You have to read the block you're writing to from the disk drive, merge the 512 bytes, and write it back. For cases where you're writing a 132 byte chunk of data to the middle of a file on a block boundary, you have to copy the first part to one block (read, copy, write) and the other half to the other block (read, copy, write). > (In fact, everybody's mother except the floppy trackdisk device does > this). That isn't to say copying is never used.... it is used quite a bit in > the OS, but it isn't used 100% of the time. I'd say it's used most of the time. How many programs check the size of the disk blocks being referenced and adjust their I/O requests to match? A program that's efficient under the SFS will definitely be a hog on the FFS. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?