🚀 go-pugleaf

Hallo nochmal...

martintauchmann@bigfoot.com writes:

>Es gibt ne neue evaluation Version 1.4 von `Future Drive Accelerator`, mit
>der jetzt auch das Schreiben m�glich ist! Dadurch gibt es weniger
>Diskzugriffe.

/* snip */

>Kurzum, es ist das beste Disk-Cache Programm in der gesammten Computerwelt.

Ich w"urde Dir gerne zustimmen, aber es gibt ein paar Dinge, die mich wurmen,
zumindest was die vorherigen FPA-Versionen angeht. Wenn Du das alles mittler-
weile korrigiert hast - um so besser! (-;

o) Im Interesse Deiner User: Sieh' Dich doch bitte nach einem neueren Compiler
um. Der Oberon (war dem so?) Compiler mag zwar nett sein, aber der erzeugte
Code sieht recht grausam aus. Das w"are ja noch egal, aber der von dem 
Startup-Code installierte Exception-Handler stammt aus 68000-Zeiten und kann
mit den Stackframes des 68020 bis 68060 gar nichts anfangen. Im Falle eines
Falles erzeugt er nur schlimmere Fehler als er beheben soll, n"amlich 
Abst"urze. Nebenbei: Auch andere Programme haben damit Probleme, AsmPro z.B.

Ich lege Dir einen C-Compiler ans Herz, "Dice-C" oder der "vbcc" sind gar 
nicht mal schlecht und frei im Aminet verf"ugbar.

o) Wichtig: Allocate() ist eine Funktion zur privaten Speicherverwaltung. 
Es wird "ubergeben: Ein MemHeader. Nicht mehr, nicht weniger. Dieser 
MemHeader *IST NICHT NOTWENDIG* Teil eines exec.library-kompatiblen Speicher-
pools, sondern eben privat f"ur das Programm, das ihn verwendet. Die Gr"unde, 
warum ich bei VNC andere Pools verwende, sind manigfaltig. Erstens, weil es
AllocPooled() erst seit V39 gibt und VNC auch auf V37 (und sogar auf V33) 
l"auft. Zweitens, weil Mikes Implementierung buggy ist und erst von SetPatch 
repariert wird, ich wei"s aber nicht genau, ab welcher Setpatch-Version das 
passiert und ob der User die auch wirklich verwendet. 

Drittens: Wer sagt eigentlich, dass AllocPooled() Allocate() aufruft? Das 
stimmt zwar f"ur den von SetPatch installierten Patch, aber nicht f"ur die Os
Orginalroutinen, seien sie nun buggy oder nicht.

Ich sehe keinen Sinn darin, diese Funktion zu patchen und damit in die 
interne Speicherverwaltung von Applikationen einzugreifen, Allocate() ist
und bleibt TABU.

In die gleiche Richtung: Auch die mmu.library verwendet die Allocate()-Routine,
und auch die Pools der mmu.library sehen anders aus als die von Exec. Auch
in diesem Falle habe ich Gr"unde daf"ur: Die MMU-Speicherbl"ocke m"ussen zum
Teil auf bis zu 32K-Grenzen ausgerichtet werden, das ist mit AllocPooled() 
nicht zu wollen, und auch nicht, falls irgendein Programm in die interne 
Speicherverwaltung eindringt. 

Anders ausgedr"uckt: Ich gehe ja auch nicht in Deinen Keller und lege meine
Diskettenarchive da ab, weil ich keinen Platz mehr habe und bei Dir "noch
frei ist". Davor ist ein Schild "privat", und das habe ich zu respektieren. (-;

o) Es ist keine schlaue Idee, AvailMem() zu patchen, um die RAM-Disk schneller
zu machen. Der Ram-Handler ruft AvailMem() deshalb auf, um den Speicher nicht
ganz zulaufen zu lassen und um zu verhindern, dass durch Vollladen der Ram-Disk
Libraries aus dem System entfernt werden. Dieses AvailMem() ist auch dazu 
gedacht, beim Volladen der Ram-Disk wenigstens noch genug Speicher zu haben, 
um einen Fehlerrequester sicher anzeigen zu k"onnen. Es lohnt sich, dar"uber 
wirklich mal gr"undlich nachzudenken, glaub' mir...

o) Ich wei"s nicht, ob ich das schon sagte, aber ein AllocMem() oder FreeMem()
darf den "Forbid()" oder "Disable()"-Status nicht brechen. Nur f"ur den Fall,
dass Du versuchst, ein Copyback-Cache zu realisieren: In einem gepatchten
AllocMem() darfst Du *nicht*, *niemals nie* DoIO() aufrufen, etwa um den
Cache zur"uckzuschreiben. Bedenke, die einzige Methode, *sicher* eine der
Exec-Listen z.B. auf der Konsole auszudrucken, ist erst Forbid() aufzurufen,
danach eine Kopie der Liste mit AllocMem()-Aufrufen zu erstellen, dann Permit()
und dann die Liste auszudrucken. Ein (implizites) Wait() in AllocMem() w"are
hier FATAL. Ich sehe hier zumindest ein gro"ses Problem f"ur einen solchen
Cache-Modus. 

Gut, ich denke, Du bist kompetent genug, das zu wissen.

o) Speicherverwaltung allgemein: Ich halte es f"ur keine so gute Idee, einfach
frei herumliegende MemChunks zu nehmen und zu f"ullen. Ich wei"s nicht, wie
FPA genau arbeitet, aber wenn es so arbeitet, m"ochte ich eine andere Alter-
native vorschlagen, die unabh"angig von der exec-internen Chunk-Verwaltung ist.
Am geeignesten erscheint es mir, den Speicher wie gehabt mit AllocMem zu
holen, ggf. mit MEMF_REVERSE verziert, und ggf. AvailMem() zu patchen, um 
Programme dazu zu ermuntern, weiterhin Speicher wie gehabt zu allozieren.
FreeMem() kannst Du immer noch aufrufen, wenn Du den Speicher nicht mehr als
Cache brauchst. Ich sage das deshalb, weil bei anderem Vorgehen FPA ziemliche
(und berechtigte) Probleme mit Applikationen wie dem GuardianAngle, CyberGuard,
dem GuardianAngleRemix und dem in Entwicklung befindlichen MuGuardianAngle
haben wird.

Ich bitte Dich, diese Punkte einmal sachlich zu "uberdenken und diese Kritik 
nicht als pers"onliche Beleidigung aufzufassen. So ist's n"amlich nicht
gemeint. Im Interesse Deiner User, bitte. Ich denke schon, dass es FPA zum
"besten" Cache-Programm schaffen kann, aber das bedeutet auch, dass Du Dir
von Zeit zu Zeit die N"orgeleien der User anh"oren musst. So ist das 
eben... (-;


Gr"u"se,
	Thomas Richter

______________don't_cut_here,_it_could_damage_your_terminal____________________
 _______         _____  _____          
    /    /    / /    / /    / EMAIL: thor@einstein.math.tu-berlin.de           
   /    /____/ /    / /____/ http://www.math.tu-berlin.de/~thor/thor/index.html
  /    /    / /    / /   \  PGP available on request, finger print:        
 /    /    / /____/ /    / 11 FC 46 B0 7F 42 43 AC  38 A4 78 9A 24 BC 77 BE    
_______________________________________________________________________________

In article <7h629n$kmq$1@nnrp1.deja.com>,
	martintauchmann@bigfoot.com writes:

> Es gibt ne neue evaluation Version 1.4 von `Future Drive Accelerator`, mit
> der jetzt auch das Schreiben m�glich ist! Dadurch gibt es weniger
> Diskzugriffe.
> 
> Die wichtigsten Features:

> o Schreibzugriffe werden gesammelt, um sp�ter, beim Zur�ckschreiben zum
>   Laufwerk, den Schreibkopf von der h�chsten zur niedrigsten Adresse,
>   "gleiten" zu lassen.

Da kommst du zu sp�t. Sowas haben Unixe --- auch alle verf�gbaren Amiga-Unixe
--- seit 20 Jahren.

	-is