Forwarded ....

[shenson@nyx10.cs.du.edu (Stephen Henson)]

Return-Path: <Stephen.Usher@earth.ox.ac.uk>
Received: from earth.ox.ac.uk by nyx10.cs.du.edu (4.1/SMI-4.1)
	id AA25893; Sat, 22 Jan 94 05:17:09 MST
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver.  The University has neither control over nor
	responsibility for the opinions or correct identity of users.
From: Stephen Usher <Stephen.Usher@earth.ox.ac.uk>
Received: from elvis.earth.ox.ac.uk by earth.ox.ac.uk; Sat, 22 Jan 94 12:19:08 GMT
Message-Id: <2264.9401221219@elvis.earth.ox.ac.uk>
Subject: Re: Binary config and fork() ...
To: shenson@nyx10.cs.du.edu (Stephen Henson)
Date: Sat, 22 Jan 1994 12:18:59 +0000 (GMT)
In-Reply-To: <9401211942.AA05263@nyx10.cs.du.edu> from "Stephen Henson" at Jan 21, 94 12:42:48 pm
X-Mailer: ELM [version 2.4 PL11]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Content-Length: 2313      
Status: R

>	Yes you can use the symbol table to implement binary configuration,
>that's what my (unreleased) Minixfs binary config program does. It also why
>I originally wrote nlist(). I think with arrays you can't really increase
>their length safely by fiddling with the reloc table (what if the compiler
>or code uses an offset as an optimisation to acces a later variable?). Anyway
>I've written a short file which gives the basic idea and I'll send it when
>I've checked out a couple of sample programs.
>	Re non-blocking fork(). I think this could cause problems. At present
>(or as far as I can gather without mem protection on my STE) the virtual
>addresses are always the same as the physical ones. If you change this (and
>it is compulsory for fork()) then you get DMA problems. E.g. suppose I make
>a call to Fread. What address should the OS pass down? If the data is to be read
>directly into the buffer via DMA then you need to pass the physical address, if
>it goes via a cache you need the virtual address. If the hard disk software
>uses an internal cache then it's even more fun ...

Hmm... I've never played with DMA myself, but I know the problem you're
talking about.

Concidering that hard disk software will be run before MiNT starts up it
will always run in a real address space. All we need to do to stop conflicts
in the future is to (a) compartmentalise DMA using kernel routines, letting
the kernel do all the address translations, and possibly remapping pages so
as to create a contiguous memory block, and (b) add a new memory allocation
call, say, dmamalloc() which will create a contigous memory region and
return a physical address. I admit this would break programs which were not
virtual-memory aware which go straight for the hardware.

The main problem I see is catering for the ST{F,FM,M} series machines, those
with mere 68000's. The only way I can see a non-blocking fork being
implemented is via shadowing, as used in Minix.. and does that slow the
machine down or what?

>Steve.

Steve

-- 
---------------------------------------------------------------------------
Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
E-Mail: steve@uk.ac.ox.earth (JANET) steve@earth.ox.ac.uk (Internet).
Tel:- Oxford (0865) 282110 (UK) or +44 865 282110 (International).