![]() |
Erkennen von Bereichskonflikten bei doppelten Adressen
Ich ermittle mit einem Programm die verwendeten Speicheradressen der eingebauten PCI-Geräte und möchte prüfen, ob es hier Konflikte - also doppelt verwendete Adressen gibt. Dabei habe ich ein grundsätzliches Problem bei der Lösung dieser Funktion.
Ermittelt werden bspw. für 3 PCI-Karten folgende Speicherbereiche: PCI Karte 1 - Speicherbeginn 0000FF00h - Speicherende 0000FF07h PCI Karte 2 - Speicherbeginn 0000FF00h - Speicherende 0000FF07h PCI Karte 3 - Speicherbeginn FD800000h - Speicherende FD8FFFFFh Bisher habe ich die Daten in einem 2 dimensionalen Array jeweils mit Anfangs- und Endadresse gespeichert. Nun ergibt sich aber das Problem, dass ich prüfen muss, ob Speicherbereiche doppelt verwendet werden. Mit StringListen habe ich schon experimentiert, etwa indem die Hex-Werte in Strings umgewandelt und in der Liste gespeichert werden. Damit kann ich aber nur doppelte Anfangs- und Endadressen aufspüren, nicht die eigentlichen Bereiche. Welchen Ansatz könnte man hier idealerweise verfolgen ? Bin über jeden Vorschlag dankbar. |
Re: Erkennen von Bereichskonflikten bei doppelten Adressen
Zitat:
|
Re: Erkennen von Bereichskonflikten bei doppelten Adressen
Nicht immer korrekt, weswegen mein Programm eine Art Verifizierung der Adressen durchführen muss.
Die Ermittlung steht schon, ich muss nur einen Weg finden, die ermittelten Adressen zu vergleichen bzw. Konflikte zu erkennen. |
Re: Erkennen von Bereichskonflikten bei doppelten Adressen
Zitat:
|
Re: Erkennen von Bereichskonflikten bei doppelten Adressen
Ich möchte etwa folgende Aussage treffen können:
Der Speicherbereich von PCI Karte 1 kollidiert mit dem Speicherbereich von PCI Karte 2 und könnte für ein instabiles System verantwortlich sein. In meinen Augen viel wichtiger ist der Weg bis dahin, nicht das Ziel. |
Re: Erkennen von Bereichskonflikten bei doppelten Adressen
Willst Du nun pruefen, ob sich mehrere PCI Karten, welche sich auch Speichermaessig ueberlappen können, mit einer anderen (ja moeglich iss ala Sharing)..sich behindern?..das ist wohl kaum moeglich :?:
|
Re: Erkennen von Bereichskonflikten bei doppelten Adressen
Ja, es geht dabei um Sharing. Nur eben nicht Interrupt-Sharing, sondern Speicher-Sharing. Aber warum das nicht möglich sein kann, ist für mich nicht nachvollziehbar.
Adressen (hier die Beginn- und Endadresse) sind auch nur Zahlen und es muss eine Möglichkeit geben, die Überlappung einer doppelten Adresse zu prüfen. Vielleicht muss ich noch etwa experimentieren... |
Re: Erkennen von Bereichskonflikten bei doppelten Adressen
Wenn ich Dein Problem richtig interpretiere, ist die Lösung eigentlich ganz einfach:
Du musst alle Anfangs- und Endadressen mit den zugehörigen Nummern der Karten jeweils in einen Record schreiben und dann die Records in eine Liste einsortieren nach der Grösse der Adresse. Dann nimmst Du Dir eine Stringliste und gehst die obige Liste v.l.n.r. durch. Wenn du dann einen Adressbereich einer karte betrittst, trägst Du die Nr im Record in die Stringliste ein. Wenn Du in der Stringliste dann zu irgendeinem Zeitpunkt mehr als 1 eintrag stehen hast, hast Du einen Adresskonflikt. Das Checkst Du natürlcih immer direkt nach dem Eintragen. So, das sollte als Idee zum Implementieren wohl reichen ;-) |
Re: Erkennen von Bereichskonflikten bei doppelten Adressen
Hallo Devid,
unabhängig von deinem Anwendungsfall - du musst Intervalltest durchführen:
Delphi-Quellcode:
Getippt und nicht getestet.
uses
Math; function IntersectRange(min1, max1, min2, max2: Int64; var min3, max3: Int64): Boolean; begin Result := InRange(min1, min2, max2) or InRange(max1, min2, max2) or InRange(min2, min1, max1) or InRange(max2, min1, max1) ; if Result then begin min3 := Max(min1, min2); max3 := Min(max1, max2); end; end; Grüße vom marabu |
Re: Erkennen von Bereichskonflikten bei doppelten Adressen
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:38 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz