Mail Archives: djgpp/1995/09/29/12:37:32

Xref: comp.os.msdos.djgpp:2280
From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Locking mem under DPMI
Date: Fri, 29 Sep 1995 07:51:32 CDT
Organization: Rice University, Houston, Texas
Lines: 22
References: <DFLDA9 DOT Hqp AT goodnet DOT com> <Pine DOT SUN DOT 3 DOT 91 DOT 950928204714 DOT 14181A-100000 AT engr DOT engr DOT uark DOT edu>
Reply-To: sandmann AT clio DOT rice DOT edu
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway: from newsgroup comp.os.msdos.djgpp

> Last question, is there any reason preventing auto-locking of the 
> iret/callback wrappers and interrupt stack space in subsequent compiles 
> of libc.a?  It seems that right after the malloc would be the perfect 
> place to go ahead and lock it.  For the .beta3 release I went ahead and 
> patched the libc sources, are there any side effect I should be aware of?

This should be done.  If you have patches to do this, please put them
on in the incoming directory.  Everyone has just been too 
busy with other things to get to it.  I would also suggest locking 4096
bytes after the starting address of the wrapped function.  Since most
interrupt routines should be fairly short, I would guess this would
automatically handle 99% of the cases, and locking an extra page of
memory won't hurt anything.

At that point, it would be up to the user to lock any data they touch
or any subroutines they might call (and to make sure their code is less
than 4096 bytes or lock the rest...).  This seems like it would not be
too difficult.  I also think we need a simple wrapper function that
automatically adds the CS base to this, so something like
  __djgpp_lock_memory(void *, unsigned size_in_bytes)
(which could even use the global value declared in sys/nearptr.h to make
it even easier).  I think Mat posted a routine that did this once.

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019