/*	
 * 	mm/mms_stub.c
 *	(C) 1995 Chad Page
 *
 *	This file defines the base-level interfaces for MMS so that 
 * 	the rest of the kernel can do memcpy_touser without ever knowing
 * 	that MMS even exists.  (It also documents the interfaces to MMS :) 
 */

#include <linux16/types.h>
#define MMS_STUBS
#include <linux16/mms_base.h>

/* It is assumed this is initialized by arch_init before *any* function in
 * this file is called! */
__mms_ops global_mm;

__pmms_info mms_init()
{
	return global_mm->init();
}

/***********************************************************************
	memcpy functions
************************************************************************/

__pvoid memcpy_togb(h, dest, src, len)
__hglobal h;
__pvoid dest;
__pvoid src;
__uint len;
{
	return global_mm->memcpy_togb(h, dest, src, len);
}

__pvoid memcpy_fromgb(h, dest, src, len)
__hglobal h;
__pvoid dest;
__pvoid src;
__uint len;
{
	return global_mm->memcpy_fromgb(h, dest, src, len);
}

/* memcpy_user provides the kernel a way to copy within a DS, if it's ever
 * needed (I don't know, but it *might* become useful.) */

__pvoid memcpy_ingb(h, dest, src, len)
__hglobal h;
__pvoid dest;
__pvoid src;
__uint len;
{
	return global_mm->memcpy_ingb(dest, src, len);
}

__pvoid memcpy_gbs(ha, dest, hb, src, len)
__hglobal ha, hb;
__pvoid dest;
__pvoid src;
__uint len;
{
	return global_mm->memcpy_gbs(ha, dest, hb, src, len);
}

/*************************************************************************
	global heap functions
**************************************************************************/

/* 
 * Yes, these are rip-offs of Windoze memory calls.  The thing is that they're
 * actually useful in this case, since if our (real mode) apps are written
 * well enough, we can use these APIs safely and get garbage collection.  If
 * we don't need it (say, we're calling DPMI), nothing forces us to use a 
 * garbage collector in that case.
 * 
 * Combined with good binary loader code, the MMS system should work well
 * with EMS as well.
 *
 * Practically, if we want a good real mode OS, we have to use garbage 
 * collection if we want the apps to have malloc() in their libc, or else
 * face 64K dsegs every time, which gives us, uh, about 6 apps in RAM. 
 *
 * So, MMS draws a lot from Windoze in an important area... sigh.
 */

__mms_ret mms_global_alloc(len, flags, h)
__uint len;
__u16 flags;
__phglobal h;
{
	return global_mm->global_alloc(len, flags, h);
}

__mms_ret mms_global_free(block)
__hglobal block;
{
	return global_mm->global_free(block);
}

__mms_ret mms_global_lock(block, p)
__hglobal block;
__pvoid * p;
{
	return global_mm->global_lock(block, p);
}

__mms_ret mms_global_unlock(block)
__hglobal block;
{
	return global_mm->global_unlock(block);
}

__mms_ret mms_global_resize(block, newsize)
__hglobal block;
__uint newsize;
{
	return global_mm->global_resize(block, newsize); 
}

/* This activates the garbage collector, if needed+available.  It returns
 * the biggest block allocatable (may be below, equal to, or bigger than
 * reqsize), according to the amount of free memory. 
 * 
 * Within MMS, this will probably be called by global_alloc and global_resize
 * because it does a nice check of memory availability. 
 */
__mms_ret mms_global_compact(reqsize, actsize)
__uint reqsize;
__puint actsize;
{
	return global_mm->global_compact(reqsize, actsize);
}

/************************************************************************
	process functions
*************************************************************************/

/*
 * The process-level functions will make it possible for Linux/16 to run with
 * any kind of memory manager.  Anything related to segment registers (in x86)
 * will be routed into MMS to make the code as a whole much more portable.
 * If EMS support is done (I hope :) we can even use a paging-like model to
 * run Linux/16 apps in.  I expect that 2MB of EMS RAM will greatly increase
 * the number of apps that Linux/16 can run to the point where many users
 * can use a Linux/16 box at once without RAM cram (okay, it'll be slow :)
 */

/* 
 * This function will prepare a task for execution (and automagically unprepare
 * the current task if needed.)  It will return MMS_OK if the application is
 * loaded okay, and probably will return MMS_NOMEM if the task is swapped and
 * there is no space to unswap it.
 * 
 * Basically, mms_prepare_process will lock hglobals used by the task and
 * set up the registers so it will be able to switch to the task.
 */ 

__mmsret mms_prepare_process(task)
__ptask task;
{
	return global_mm->ready_process(task);
}

/* 
 * This function will unlock task memory, etc... 
 */

__mmsret mms_unprepare_process(task)
__ptask task;
{
	return global_mm->unprepare_process(task);
}

/* A wrapper function for allocating code, data, and stack may go here... */



