virtuelle adressen in physikalische adressen umwandeln

[ToniR]

Hallo!

Ich habe das Problem, dass ich die Adresse eines Buffers in meiner Delphi-Anwendung an ein PCI-Gerät übergeben muss, dass daraufhin die Daten in diesem Buffer in kleinen Häppchen ausliest. Dazu muss ich aber die echte physikalische Adresse des Buffers übergeben und nicht die virtuelle Adresse, die ich von der WinAPI-Funktion GlobalAlloc(GMEM_FIXED, ...) bekomme.

Ich habe schon verzweifelt nach einer einfachen Lösung für mein Problem gesucht, bin bis jetzt aber nicht fündig geworden.

Vielleicht kann mir ja hier jemand weiterhelfen.

Viele Dank im Voraus

ToniR

[Olli]

Also ich weiß ja nicht von welchem Zielbetriebssystem wir hier reden, aber der korrekte Weg führt in jedem Fall über einen Treiber. Wobei es verschiedene I/O-Formen (unbuffered, etc) gibt. Der Treiber kümmert sich dann normalerweise um den Rest (z.B. korrekte Adressierung). Übrigens, entgegen allgemeiner Befürchtungen, wird die Performance von dem extra Layer (Treiber) nicht beeinträchtigt - oder zumindest nur sehr unwesentlich.

Kannst du ein wenig mehr Informationen geben?!

Achso, Nachtrag:
An die physikalische Adresse kommst du normalerweise nur mit dem Zugriff, den ein Treiber dir bietet (in NT ist das sehr strikt getrennt). Der Treiber wiederum sollte es dir ermöglichen eine virtuelle Adresse innerhalb deines Prozesses zu erhalten, die "auf den physischen Teil" zeigt. Das funktioniert mit MmMapIoSpace(). Schau dir dazu am besten das DDK mal an. Das gibt es IMO auch online bei MSDN.

[SirThornberry]

also bei drag & drop geht das ganze mit

Delphi-Quellcode:

GlobalAlloc(GMEM_SHARE or GMEM_MOVEABLE

(also nicht fixed)
und anschließend
"GlobalLock"
schau dir dazu aber die Hilfe an...

Drag&Drop Beispielquelltext (zum senden einer solchen Message)
http://www.delphipraxis.net/internal...=333892#333892

[Olli]

Hi SirThornberry,

sei mir nicht böse, aber ich habe das Gefühl, du hast die Frage nicht verstanden. Das was du mit Windows (egal von welchem Heap du reservierst) bekommst ist immer virtueller Speicher im Usermode.

Gruß,

[SirThornberry]

hmm, jetzt wo du's "sagst" - > stimmt. ich weiß ja aber auch nicht in wie weit das ansteuern über einen treiber läuft. Vielleicht läuft es ja über die Einbindung einer DLL und dementsprechend würde es damit funktionieren.

[Olli]

Zitat:

Zitat von SirThornberry

hmm, jetzt wo du's "sagst" - > stimmt. ich weiß ja aber auch nicht in wie weit das ansteuern über einen treiber läuft. Vielleicht läuft es ja über die Einbindung einer DLL und dementsprechend würde es damit funktionieren.

Also ob du einen Treiber über eine weitere Abstraktionsschicht (DLL) ansprichst bleibt dir meist überlassen, wenn du denn die IOCTLs kennst, mit denen man den Treiber ansteuern kann ;)

[ToniR]

Hallo Olli,

das Betriebssystem ist WinXP, aber der Aufwand, mich in die Treiber-Programmierung einzuarbeiten, war mir bis jetzt zu groß, da ich ja lediglich einmal die physikalische Adresse meines Buffers benötige. Aber so wie es scheint, bleibt mir wohl nix anderes übrig. Ursprünglich dachte ich mal, dass da ein einfacher API-Call genügen würde, aber Windows ist da wirklich sehr restriktiv (wohl zurecht).

Falls doch noch jemand einen "einfacheren Weg" kennt, wäre ich jedenfalls sehr, sehr dankbar!

Gruß

ToniR

[Olli]

Hast PN von mir ;)

[Muetze1]

Moin!

Das auslesen der lokalen Deskriptortabelle sollte nicht privilegiert sein, daher könnte er es sich darüber selber ermitteln wo die physikalische Adresse liegt.

MfG
Muetze1

[Olli]

Kannst du das mal genauer spezifizieren. Ich sehe noch nicht, wo man mit der LDT weiterkommt. Habe mir eben nochmal ein Kapitel eines Assemblerbuches zu Gemüte geführt und sehe noch ;) keinen Sinn in der Aussage.


Mit Gruß und Bitte um Aufklärung,

[Olli]

Zu GMEM_FIXED. In einer PM tauchte die irrtümliche Annahme auf, daß dieses Flag dafür sorgt, daß der Speicher nicht geswappt (ausgelagert) werden darf. Dies ist nicht korrekt. Windows bietet allein Treibern die Möglichkeit zu wählen, wobei der sog. NonPagedPool als sehr begrenzte Ressource anzusehen ist. Ansonsten kümmert sich der MM um den Rest. Was bedeutet also GMEM_FIXED?
Nun, normalerweise geben die Global*()-Funktionen ein Handle zurück. Dieses Handle kann dann benutzt werden um einen Speicherbereich zu sperren und so einen Pointer darauf zu erlangen. Ist ein Bereich gesperrt, so darf sich die Adresse nicht verändern. Ist ein Bereich entsperrt, so kann der entsprechende Speicherblock, der durch das Handle repräsentiert wird, verschoben werden. GMEM_FIXED veranlaßt, daß der Speicherbereich immer gesperrt ist und somit das Handle auch als Pointer benutzt werden kann (Typecasting).

@ToniR: Ich habe nochmal ins DDK geguckt. Einen Treiber zu schreiben, der nur einen IOCTL hat, welcher dann eine phys. Adresse in eine virtuelle Adresse umwandelt sollte kein Problem sein. Allerdings bin ich mir noch nicht sicher, ob es so einfach geht diesen Bereich für den jeweiligen Prozess sichtbar zu machen. Am besten wäre wohl eine Section (MMF), denke ich. Es wird aber davon abgeraten und ich würde auch eher für das Kopieren eines Puffers. Kann man den DSP nicht stückchenweise füttern?

[ToniR]

Zitat:

Zitat von Olli

wobei der sog. NonPagedPool als sehr begrenzte Ressource anzusehen ist.

Wie groß ist denn dieser NonPagedPool (ein bestimmter Prozentsatz vom Hauptspeicher?), bzw. wieviel Speicher kann ein Treiber davon belegen?
Ist die Größe dieses Pools konfigurierbar?

[Olli]

Zitat:

Zitat von ToniR

Zitat:

Zitat von Olli

wobei der sog. NonPagedPool als sehr begrenzte Ressource anzusehen ist.

Wie groß ist denn dieser NonPagedPool (ein bestimmter Prozentsatz vom Hauptspeicher?), bzw. wieviel Speicher kann ein Treiber davon belegen?
Ist die Größe dieses Pools konfigurierbar?

Auf jeden Fall maximal so groß wie der echte RAM ;)

Ein Treiber sollte möglichst wenig davon belegen und nur wenn nötig. Wie gesagt, wenn man PagedPool benutzt, heißt dies nicht daß alles gleich ausgelagert wird, aber Windows kümmert sich dann selbst darum.

[Robert Marquardt]

Ich glaube du stocherst im Dunkeln herum.
Zur Ansteuerung eines PCI-Geraetes ist zwingend ein WDM-Treiber erforderlich.
Zur Treiberentwicklung braucht man das Windows 2003 DDK (CD bei MS bestellen, kostet nur eine Gebuehr fuer das Versenden).
Visual Studio ist nicht zwingend notwendig, aber sehr nuetzlich. Im DDK ist ein Beispieldriver fuer PCI enthalten.
Ohne C Programmierung geht garnichts, ohne reichlich WDM-Treiberwissen kaum mehr.

[Olli]

Zitat:

Zitat von Robert Marquardt

Ich glaube du stocherst im Dunkeln herum.
Zur Ansteuerung eines PCI-Geraetes ist zwingend ein WDM-Treiber erforderlich.

Vielleicht wenn du eine Zertifizierung brauchst (und PnP und Powermanagement), ansonsten tut's auch noch gut ein Treiber im NT4-Stil *grins*. Außerdem, was von oben gesagtem ist bei WDM-Treibern anders? Ich sehe noch nix ;)

Also das aktuelle Problem scheint mir zu sein, daß ein Treiber benutzt wird, welcher, nunja man ahnt es schon, generischen Zugriff bietet. Würde man diesen generischen Zugriff auf das entsprechende Gerät zurechtschneidern, wäre dies vermutlich besser. Dazu braucht's allerdings erstmal die Spezifikationen des Gerätes und einer gewissen Testphase, plus jede Menge Zeit!

[Robert Marquardt]

Ein VxD-Treiber statt einem WDM-Treiber? Das heisst den Beelzebub mit dem Teufel austreiben :->
Letztlich geht es aber darum das virtuelle adressen in physikalische adressen nur im Treiber umgesetzt werden koennen.
Ueblicherweise schreibt man seine Daten per DeviceIoControl an den Treiber und der verfuettert die Daten (meist scheibchenweise) dann an das Geraet.

[Olli]

Zitat:

Zitat von Robert Marquardt

Ein VxD-Treiber statt einem WDM-Treiber? Das heisst den Beelzebub mit dem Teufel austreiben :->

:shock: ... du weißt sicher worüber du redest? Ich sagte NT-Treiber! VxDs sind für Windows 9x/Me gedacht und haben äußerst wenig mit dem NT-Treibermodell zu tun, geschweige denn dem WDM. Man kann aber sehr wohl ältere NT-Treiber oder Nicht-WDM-Treiber von Windows 2000 auf höheren NT-OSen benutzen (nicht immer aber oft).

Zitat:

Zitat von Robert Marquardt

Letztlich geht es aber darum das virtuelle adressen in physikalische adressen nur im Treiber umgesetzt werden koennen.
Ueblicherweise schreibt man seine Daten per DeviceIoControl an den Treiber und der verfuettert die Daten (meist scheibchenweise) dann an das Geraet.

Hatte ich oben erwähnt, wurde aufgrund von Performanceproblemen als nicht machbar verworfen.