Date:	Tue, 9 Jul 1996 09:00:03 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"Alaric B. Williams" <alaric AT abwillms DOT demon DOT co DOT uk>
Cc:	djgpp AT delorie DOT com
Subject:	Re: Locking RAM for hardware interrupts
In-Reply-To:	<836858848.164.0@abwillms.demon.co.uk>
Message-Id:	<Pine.SUN.3.91.960709084543.1036F-100000@is>
Mime-Version:	1.0

On Mon, 8 Jul 1996, Alaric B. Williams wrote:

> Well, I've seen three approaches to this problem:
> 
> 
> A) Pray. Leave pages unlocked and hope they don't get swapped out
> B) Masochism. Write the interrupt in assembler and all that, as
> scribed in the FAQ
> C) Allegro's function-pointer-marker thing, which seems a good idea,
> but can we guarantee the ordering of functions to be correct?

There is another approach: get the sample interrupt handlers donated by 
Martynas Kunigelis and use them as starting point.  This is available 
from the DJGPP ftp server as
 ftp://ftp.delorie.com/pub/djgpp/contrib/sample-interrupt-handlers-v2.zip

If that tutorial is not good enough, maybe it could be improved by people 
who use it?  Maybe even by you?

> My proposal is: make a crt0 flag that locks the /program image/ rather
> than /all memory/. It should be real easy to know where the image
> starts and ends!

You can do that yourself, using the symbols `start' and `etext':

	extern unsigned start __asm__ ("start");
	extern int etext;

`start' is defined on crt0.s and `etext' is defined by the linker.  Use
the addresses of these two to lock the code. 

> Lock the lot, and leave the programmer responsible
> for locking dynamically allocated blocks (which are usually the
> candidates for paging, since they can be huge bitmaps etc. unlikely to
> be declared as static data).

I'm not sure this is a safe solution for every program.  There might be 
cases when you don't really have control of all the data that is touched 
by the interrupt handler.

- Raw text -