[gs-code-review] add %ram% device support

[david zuhn]

Here is a set of patches that is a start at implementing the %ram*%
family of devices.   These follow the suggestion of using a directory
in /tmp (or other suitable location) and real files on disk rather
then a filesystem implemented solely in-memory.

These patches address bug 226943,

http://bugs.ghostscript.com/show_bug.cgi?id=226943

These are not yet complete, for the known reasons listed below.
However, I think they're far enough along to allow me to ask a couple
of questions about how to proceed.

1.  This is only tested on Linux/x86 and Linux/AMD64.  Those are the
   only platforms that I have development access to these days.
   The code uses mkdtemp, the status of which on Windows & MacOS
   I do not know.   I don't think anything else is horribly non-portable.
   See gp_unifs.c/gp_create_scratch_directory.

2.  There is OS level code in the gsioram.c file (which implements the
   %ram*% devices.   This is opendir/readdir, plus unlink and rmdir.
   Again, I don't know if this is sufficiently portable for Win32 &
   Mac, or if I need to abstract that code out of gsio* files and into
   some compatibility layer.
   See gsioram.c/ramdisk_delete_all_files

3.  The put_params code is needed by my reading of the PS Supplement,
   since InitializeAction is required to erase all existing files.

4.  This device always creates a gsram-XXXXXX temporary directory
   when initialized.   From what I can tell, this introduces a need
   for a shutdown process for devices.  I've added the field to the
   device structure, and to all of the rest of the devices (which
   clearly don't need one).   But I'm having trouble following the
   end-of-process code to figure out the best place to call a
   proposed new gs_iodev_shutdown function that will call the shutdown
   hook from procs.

   I think that an explicit call to a new gs_iodev_shutdown is better
   than playing games with atexit.   Agreed?

5.  BlockSize and LogicalSize have no real meaning in this code.  I have
   a start at some real in-ram based code which do make use of these
   values.   Suggested alternatives for the current defaults are welcome.
   See gsioram.c/ramdisk_get_params


This patches have been developed against GS 8.54.  Brief examinations of
the SVN trunk lead me to believe that updating this patchset will be little
trouble.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ramdisk-v8.54.patch
Type: text/x-patch
Size: 71428 bytes
Desc: not available
Url : http://ghostscript.com/pipermail/gs-code-review/attachments/20060930/c2e64318/ramdisk-v8.54-0001.bin