mint-1.10h6

[hohmuth@inf.tu-dresden.de (Michael Hohmuth)]

I've put up a sixth re-sync patch...

It contains Andreas Schwab's patches for running ROM-AES under memory
protection, Juergen Lock's patches for the memory protection problems,
for BIOS, and misc. bug fixes, and a small change by myself (I moved
"#define INLINE" from various .c files to mint.h).

Now available via ftp from ftp.inf.tu-dresden.de:

    pub/atari/Mint/Kernel/mint-1.10h5-1.10h6-diffs.gz
        Diffs against the kernel patched with the first five patches.

    pub/atari/Mint/Kernel/mint-1.10-1.10h6-diffs.gz
        Diffs against the virgin kernel.

You can also get this via email by sending a message to
ftpmail@ftp.inf.tu-dresden.de containing this text in the message body:

    send pub/atari/Mint/Kernel/mint-1.10h5-1.10h6-diffs.gz
or
    send pub/atari/Mint/Kernel/mint-1.10-1.10h6-diffs.gz

After my .sig are the last few commit messages.

Bye,
Michael
-- 
Email: hohmuth@inf.tu-dresden.de
WWW:   http://www.inf.tu-dresden.de/~mh1/

**************************************

From: Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>
Subject: Memory protection without MultiTOS
Message-Id: <9407040915.AA00368@issan.informatik.uni-dortmund.de>

dosmem.c,main.c:
Here is a patch to allow running the old AES
under memory protection.  It turns all memory requests by the AES into
global accessible, so that the resource tree can be accessed by both
the program and the AES.  Also the first process started by the AES
(the real GEM process) is marked to have global memory protection.
Note that the accessories must run in global memory too, you have to
change the file header appropriately.  There are still problems with
accessories that dynamically request memory during runtime, since it
is allocated in the context of the running program and thus private by
default, but this is considered bad programming style anyway (XCONTROL
1.31 is such a beast :-/ ).

This is kind of a hack, especially the distinction between Malloc from
AES and VDI.  This only works if the AES code is located after the VDI
code in the roms, which is the case in all TOS versions i know of
(1.00, 1.02, 1.04, 3.06), but it may fall over with other versions.

**************************************

From: Juergen Lock <nox@jelal.north.de>
Subject: Re: some more 110h4 clues...
Message-Id: <9407031033.AA00399@jelal.north.de>

dosmem.c,mem.c,mem.h:
exec vs. memoryprotection, use parents MMU context in fork_restore;
look for links to the same region in fork and when calculatig process
size and also don't count sleeping fork parents memory twice...

**************************************

From: Juergen Lock <nox@jelal.north.de>
Subject: Re: some more 110h4 clues...
Message-Id: <9407031033.AA00399@jelal.north.de>

dosmem.c:
GEM/toswin memleaks:  only link M_KEEP regions to rootproc when its
the last link, then Mfree still works after a fork.  this was the only
real leak, the rootproc growing and growing mostly was a result of the
process size caculation...

**************************************

From: Juergen Lock <nox@jelal.north.de>
Subject: Re: some more 110h4 clues...
Message-Id: <9407031033.AA00399@jelal.north.de>

pipefs.c:
pipe FIONREAD: delay writer-died error condition until pipe is empty.
(can this cause problems?  i think not, and it helps for example toswin,
processes last words no longer appear 1-char-at-a-time...)

**************************************

From: Juergen Lock <nox@jelal.north.de>
Subject: Re: some more 110h4 clues...
Message-Id: <9407031033.AA00399@jelal.north.de>

proc.c:
sleep: shouldn't we keep the ipl-too-high checks?  it can still happen
outside selects...

**************************************

From: Juergen Lock <nox@jelal.north.de>
Subject: Re: some more 110h4 clues...
Message-Id: <9407031033.AA00399@jelal.north.de>

biosfs.c,dosmem.c,fasttext.c,proc.c,timeout.c,tty.c:
        some cosmetic changes to the source (some lost tabs, etc. :)

**************************************

From: Juergen Lock <nox@jelal.north.de>
Subject: Re: some more 110h4 clues...
Message-Id: <9407082023.AA00649@jelal.north.de>

mem.c: fix unauthorized access to base->p_parent in exec

**************************************

From: Juergen Lock <nox@jelal.north.de>
Subject: Re: some more 110h4 clues...
Message-Id: <9407082023.AA00649@jelal.north.de>

bios.c,biosfs.c,types.h,xbios.c:
serial lines...  use the xcon* pointers etc. available thru
Bconmap(-2), set DTR on SCC ports and hack around a bunch of BIOS bugs
while we're at it, including TIOCSBRK for SCC ports.  you still need to
load debugged drivers (before MiNT!) to get reliable flow control and
stop losing chars on all TOS versions _i_ know, your mileage may vary...
at least the remaining bugs should not affect the rest of the system
anymore. (except for the mega STe SCC/DMA hardware bug of course...)

**************************************

bios.c,biosfs.c,fasttext.c,mint.h:
        move definition of INLINE to mint.h  --hohmuth

**************************************

README.1ST: update.  --hohmuth