memory protection
Ingo Godau-Gellert
Gibts denn hier wirklich niemand, der auch Probleme hat mit memory protection
unter MiNT 1.15b8 zu arbeiten? Jetzt habe ich sogar extra mal von CBHD nach
HuSHI gewechselt - das Problem bleibt... MiNT bleibt hängen nach der Meldung,
daß XHDI1.25 vorhanden ist...
Ciao! Ingo
Holger Dammann
>Gibts denn hier wirklich niemand, der auch Probleme hat mit memory
>protection unter MiNT 1.15b8 zu arbeiten?
Memory protection hat bei mir noch nie funktioniert. Woran das liegt habe ich
wieder vergessen. Es hatte aber iirc mit den verwendeten Programmen und nicht
mit Mint zu tun.
Gruß, Holger
Ingo Godau-Gellert
HD>habe ich wieder vergessen. Es hatte aber iirc mit den verwendeten
HD>Programmen und nicht mit Mint zu tun.
Hallo, Holger!
Wie gesacht, das tritt bei mir auch OHNE Zusatzprogramme aus, habe ich
beim Booten mal alle ausgeschaltet. Daher wundert es mich ja auch so.
Ingo
Holger Dammann
>Wie gesacht, das tritt bei mir auch OHNE Zusatzprogramme aus,
Ne, ich meinte nicht nur Zusatzprogramme, sondern Programme ganz allgemein.
Leider kann ich mich nicht mehr erinnern wie das war. Vielleicht müssen die
Programme, die mit MP laufen sollen spezielle dafür programmiert werden.
Gruß, Holger
Jörg Westheide
HD>Vielleicht müssen die Programme, die mit MP laufen sollen spezielle
HD>dafür programmiert werden.
Eigentlich nicht. Es gibt lediglich 2 Regeln, die es zu beachten gibt:
1. Greife nur auf Speicher zu, der Dir gehört oder zum Zugriff freigegeben
wurde
2. Erlaube den Zugriff auf Speicher, auf den andere Programme zugreifen
müssen
Bis denn
Jörg
Holger Dammann
>Eigentlich nicht. Es gibt lediglich 2 Regeln, die es zu beachten gibt:
Das klingt ja recht einfach. Zumindest für mich als Nichtprogrammierer. Aber
werden denn diese Regeln auch eingehalten?
Viele Programme (gerade ältere) wurden ja nicht nach diesen Regeln erstellt.
Läuft den mp bei Dir?
Gruß, Holger
Jörg Westheide
HD>Das klingt ja recht einfach. Zumindest für mich als Nichtprogrammierer.
Im Prinzip ist es das auch.
Bei Punkt 1 gibt es lediglich das "Problem", daß man nicht überprüfen
kann, ob fremder Speicher für den Zugriff freigegeben wurde (außer
Try&Error). Wenn es dabei knallt (was man m.W. auch abfangen kann), liegt
aber kein Fehler im eigenen Programm vor, sondern in dem Programm, dem der
speicher gehört, da es sich nicht a Regel 2 gehalten hat.
Regel 2 ist schon etwas aufwendiger, da es zum einen 2 Möglichkeiten gibt
Speicher für den Zugriff zur Verfügung zu stellen: shared memory benutzen
oder de Speicher explizit als readable oder global anfordern.
Ersteres sollte (auch wenn es leider mur unter MiNT (und evtl. MagiC) zur
Verfügung steht) bevorzugt werden, da es auch dann noch funktioniert, wenn
jede Applikation ihren eigenen Adressraum bekommt (arbeitet nicht jemand
daran? Ich meine mal sowas gelesen zu haben...).
Letzteres ist zwar unter jedem System möglich, kämpft aber mit dem
Problem, daß manche (ältere) TOS-Systeme mit den zusätzlichen bits nicht
klar kommen
HD>Viele Programme (gerade ältere) wurden ja nicht nach diesen Regeln
HD>erstellt.
Ja, Regel 1 sollte aber auch "damals" selbstverständlich gewesen sein und
für Regel 2 gibt es eine Möglichkeit diese Programme "regelkonform" zu
machen, indem man die Protection-Flags im Header auf global setzt
HD>Läuft den mp bei Dir?
Ja
(ich benutze aber auch nicht viele alte Programme)
Bis denn
Jörg
Holger Dammann
>Ja
Hmm, dann lohnt es sich ja vielleicht auch für mich nochmal einen Anlauf
zu nehmen. Ich fürchte nur einen großen Aufwand bis das System dann wieder
stabil läuft, da ich ja alle Programme ausprobieren müßte. Oder gibt es
eine Liste mit den Programmen, die mit mp funktionieren, bzw. auch nicht
funktionieren?
Im täglichen Einsatz ist hier Thing, NVDI5, CAT, Multistrip 1.3, ... und
nicht zuletzt die Treiber für die Graka.
Gruß, Holger
Jörg Westheide
HD>gibt es eine Liste mit den Programmen, die mit mp funktionieren, bzw.
HD>auch nicht funktionieren?
Mir ist keine bekannt. Aber generell sollten eigentlich alle Programme
funktionieren, die keinen Bug haben, der bewirkt, daß sie Zugriffe
außerhalb ihres Speichers tätigen, wie z.B. über Array-Grenzen
hinausschreiben, und keine Interprozeßkommunikation über Speicherbereiche
abwickeln (z.B. AV-Protokoll).
Programme, die letzteres machen müssen halt angepaßt sein.
HD>Im täglichen Einsatz ist hier Thing, NVDI5, CAT, Multistrip 1.3, ...
HD>und nicht zuletzt die Treiber für die Graka.
Hört sich so an, als sollten die alle laufen.
Den Grafikkartentreiber und NVDI solltest Du aber (evtl.) besser vor MiNT
starten...
Bis denn
Jörg
Julian Reschke
bzw.
JW>HD>auch nicht funktionieren?
JW>Mir ist keine bekannt. Aber generell sollten eigentlich alle Programme
JW>funktionieren, die keinen Bug haben, der bewirkt, daß sie Zugriffe
außerhalb
JW>ihres Speichers tätigen, wie z.B. über Array-Grenzen hinausschreiben,
und keine
JW>Interprozeßkommunikation über Speicherbereiche abwickeln (z.B.
AV-Protokoll).
JW>Programme, die letzteres machen müssen halt angepaßt sein.
...oder die Programmflags müssen richtig stehen.
Holger Dammann
>Mir ist keine bekannt.
Schade.
>Aber generell sollten eigentlich alle Programme funktionieren,
Dann werde ich das nochmal ausprobieren.
>die keinen Bug haben,
Das werde ich ja dann merken.
BTW: Was hat denn der Speicherschutz (private, global, super, readable + share)
zu bedeuten?
Gruß, Holger
Jörg Westheide
HD>Was hat denn der Speicherschutz (private, global, super, readable +
HD>share) zu bedeuten?
Aus dem Appendix A (Memory Protection) der Mint-Doku:
-------------------------------- >8 schnipp 8<
--------------------------------
1. Private. Only the process itself (and the OS) can use the memory.
2. Global. This memory is totally unprotected.
3. Super. This memory can be accessed by anybody from Super mode.
4. Private/readable. Anybody can read, nobody else can write.
-------------------------------- >8 schnapp 8<
--------------------------------
Und zu shared memory ein Auszug aus mint.doc:
-------------------------------- >8 schnipp 8<
--------------------------------
Shared Memory
Children created with the Pexec(4,...) or with Pexec(104,...) share all of
their parent's memory, as do children created with the Pvfork() system
call.
Hence, they may communicate with their parent (or with each other) via
global variables.
A more general shared memory mechanism is provided by U:\SHM. Files in
that directory represent blocks of memory. A program may offer to share
its memory by creating a file in U:\SHM and executing an Fcntl call
(SHMSETBLK) to associate a block of memory with the file. Other programs
may then open the file and do a SHMGETBLK call to gain access to that
memory.
To create a shared memory file, a program uses the Fcreate() call
to create a file in U:\SHM, e.g.:
fd = Fcreate("U:\\SHM\\MY.SHARE", 0);
It then uses an Fcntl() call to attach a block of memory (previously
allocated by Malloc() or Mxalloc()) to the file:
blk = Malloc(128L);
Fcntl(fd, blk, SHMSETBLK);
Several things should be noted when creating a shared memory
file:
(1) The file's attributes must be 0. Read-only shared memory, or
shared memory with other attributes, is not yet implemented,
but may be in the future.
(2) Two shared memory files cannot have the same name. An attempt
to create a new shared memory file with the same name as an
existing one will fail with an access denied error (EACCDN).
(3) Once the block of memory has been attached to the file, it
may be accessed by any application that opens the file.
(4) A shared memory file (and associated block) remain allocated
even after the program which created it terminates. It can be
deleted (and the associated memory freed) with an Fdelete()
system call.
(5) The size of the shared memory file will be the actual size
of the memory block. This may be somewhat larger than the
size requested in the Malloc or Mxalloc request, due to memory
rounding.
To use a shared memory block, a client application must open
the file and use the SHMGETBLK Fcntl to gain access to it.
For example:
fd = Fopen("U:\\SHM\\MY.SHARE", 2);
blk = Fcntl(fd, 0L, SHMGETBLK);
Fclose(fd); /* optional -- see below */
Things to note:
(1) The address of the shared memory block is returned by the
Fcntl() call. NOTE THAT THIS ADDRESS MAY BE DIFFERENT FOR
DIFFERENT PROGRAMS. That is, a shared memory block that appears
at address 0x01000100 in one program may appear at address
0x0007f000 in another. In particular, shared memory blocks
should not contain absolute addresses (e.g. pointers).
(2) The extra argument passed to Fcntl() is reserved for future
expansion; use 0L for now to ensure compatibility with
future versions of MiNT.
(3) The mode argument in the Fopen() function must be an accurate
reflection of how the program plans to use the memory; read and
write access permissions will be enforced in future versions
of MiNT.
(4) If no SHMSETBLK has been made for the file, a SHMGETBLK Fcntl
will return a NULL pointer to indicate an error.
(5) If a program is finished with a shared memory block and no
longer wishes to use it, it should call Mfree() with the address
of the block (i.e. the address returned by Fcntl(fd, 0L, SHMGETBLK)).
Deleting a Shared Memory File
The Fdelete() system call may be used to delete a shared memory
file. This will *not* necessarily free the associated memory;
the memory will actually be freed only after (1) the file has
been deleted, and (2) all processes using the memory have
freed the memory, either directly or as a result of the process
terminating.
Fdelete() will fail if the shared memory file is still open.
Processes may omit the Fclose() call if they wish this to happen;
it's a way of informing the process trying to delete the file
that people are still interested in it. Note that it is *not*
harmful to allow the Fdelete to occur, since (as noted above)
the memory will not actually be freed until everyone is finished
with it; but sometimes it may be useful for programs to know that
the memory is still in use.
-------------------------------- >8 schnapp 8<
--------------------------------
Ich kann jedem der sich für solche (und andere) Fragen zu MiNT
interessiert nur empfehlen sich die Doku zu MiNT anzusehen. Die gibt's
u.a. im MiNT 1.15.0 Beta 8-Archiv (MNT115B8.TGZ, hier in der SU)
Bis denn
Jörg
Holger Dammann
>Aus dem Appendix A (Memory Protection) der Mint-Doku:
Danke. Da hätte ich nu wirklich selber drauf kommen müssen. Die Doku liegt hier
schon seit einiger Zeit rum.
>Die gibt's u.a. im MiNT 1.15.0 Beta 8-Archiv
Das werde ich mir mal besorgen.
Und dank dem Hinweis von Ulrich weiß ich jetzt auch wo sich eine Liste mit
Programmen und deren mp-Verträglichkeit auf meiner Platte rumlümmelt. Somit
konnte ich schon min. zwei "Übeltäter" dingfest machen.
Gruß, Holger