Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Benutzung von offset bei mmap

12 views
Skip to first unread message

Steffen Conrad

unread,
Dec 3, 2001, 8:10:30 AM12/3/01
to
Hi,

mein Ziel ist es, eine Datei in den Speicher zu mappen. Allerdings mach
tmir der Aufruf von mmap zu schaffen...

Dabei lese ich zuerst 6 Bytes aus, um daraus zu bestimmen, wieviele
Datensätze nun zu mappen sind.

Der Aufruf sieht folgendermassen aus:
if (1 != fread(&(n->arc_count), sizeof(lm_arc_count), 1, n->file))
return FALSE;
if (1 != fread(&(n->initial), sizeof(lm_state), 1, n->file))
return FALSE;
if (1 != fread(&(n->word_count), sizeof(lm_word_index), 1, n->file))
return FALSE;

mmap_offset = (off_t) ftell(n->file);
mmap_length = (size_t) (sizeof(lm_arcs) * n->arc_count);

if (MAP_FAILED == (n->arcs = (lm_arcs *)
mmap(0, mmap_real_length, PROT_READ, MAP_SHARED,
fileno(n->file), mmap_offset)))

Dabei ist lm_arcs ein struct.

Als Fehler bekomme ich immer EINVAL, anscheinend muss der offset
irgendwie an die Pagesize angeglichen werden. Dann könnte man doch aber
eigentlich nicht mehr sicherstellen, an welcher Position mit dem mappen
begonnen wird. Ich werde aber nicht gerade schlau daraus, ich denke,
dass mit Offset die Position bzgl. Dateianfang gemeint ist, oder?

Was genau ist nun also zu tun? Oder habe ich gerade Bullshit geschrieben
und offset bedeutet etwas ganz anderes. Leider finde ich die manpage zu
mmap an dieser Stelle nicht gerade ausführlich.

Any hints?

Gruss,
Steffen
--
Steffen Conrad # Aixplain AG
Speech Recognition # Monheimsallee 22, 52062 Aachen
Mail: s.co...@aixplain.de # Phone: 0241 189270
Phone: 0241 1892747 # http://www.aixplain.com

Falk Hueffner

unread,
Dec 3, 2001, 8:19:43 AM12/3/01
to
Steffen Conrad <s.co...@aixplain.de> writes:

> if (MAP_FAILED == (n->arcs = (lm_arcs *)
> mmap(0, mmap_real_length, PROT_READ, MAP_SHARED,
> fileno(n->file), mmap_offset)))
>
> Dabei ist lm_arcs ein struct.
>
> Als Fehler bekomme ich immer EINVAL, anscheinend muss der offset
> irgendwie an die Pagesize angeglichen werden. Dann könnte man doch
> aber eigentlich nicht mehr sicherstellen, an welcher Position mit
> dem mappen begonnen wird.

Stimmt. Kann man halt nicht. Auf den meisten Architekturen kann die
MMU nur pages mappen und keine einzelnen bytes. Steht bei mir auch so
in der man page:

offset should ordinarily be a multiple of the page size
returned by getpagesize(2).

Also musst du halt den offset abrunden und etwas mehr mappen als
noetig.

Falk

Steffen Conrad

unread,
Dec 3, 2001, 8:53:45 AM12/3/01
to
Falk Hueffner wrote:
>
> Stimmt. Kann man halt nicht. Auf den meisten Architekturen kann die
> MMU nur pages mappen und keine einzelnen bytes. Steht bei mir auch so
> in der man page:
>
> offset should ordinarily be a multiple of the page size
> returned by getpagesize(2).
>
> Also musst du halt den offset abrunden und etwas mehr mappen als
> noetig.

Hi Frank,

aber genau das ist ja das Problem. Ich möchte später auf die einzelnen
Daten per n->arcs[i].word, n->arcs[i].score etc zugreifen können und da
sollte ich schon direkt auf dem Anfang der Liste stehen. Oder muss ich
den gemappten Speicherbereich nochmal einzeln auf die Liste zuweisen?

Oder ich setze den Offset dann intern um, aber wie das geht, weiss ich
jetzt nicht so aus dem Stehgreif...

Falk Hueffner

unread,
Dec 3, 2001, 9:00:21 AM12/3/01
to
Steffen Conrad <s.co...@aixplain.de> writes:

> Falk Hueffner wrote:
> >
> > Stimmt. Kann man halt nicht. Auf den meisten Architekturen kann die
> > MMU nur pages mappen und keine einzelnen bytes. Steht bei mir auch so
> > in der man page:
> >
> > offset should ordinarily be a multiple of the page size
> > returned by getpagesize(2).
> >
> > Also musst du halt den offset abrunden und etwas mehr mappen als
> > noetig.
>
> Hi Frank,

*hust*

> aber genau das ist ja das Problem. Ich möchte später auf die einzelnen
> Daten per n->arcs[i].word, n->arcs[i].score etc zugreifen können und da
> sollte ich schon direkt auf dem Anfang der Liste stehen. Oder muss ich
> den gemappten Speicherbereich nochmal einzeln auf die Liste zuweisen?
>
> Oder ich setze den Offset dann intern um, aber wie das geht, weiss ich
> jetzt nicht so aus dem Stehgreif...

Mit Pointerarithmetik.

char* foo = mmap(...);
foo += bytes_to_skip;

Falk

Felix von Leitner

unread,
Dec 3, 2001, 12:32:22 PM12/3/01
to
Thus spake Steffen Conrad (s.co...@aixplain.de):

> aber genau das ist ja das Problem. Ich möchte später auf die einzelnen
> Daten per n->arcs[i].word, n->arcs[i].score etc zugreifen können und da
> sollte ich schon direkt auf dem Anfang der Liste stehen. Oder muss ich
> den gemappten Speicherbereich nochmal einzeln auf die Liste zuweisen?

Kannst du mal eben motivieren, was du mit einer Programmiersprache wie C
tust, wenn du elementare Konzepte wie z.B. den sicheren Umgang mit
Zeigern nicht einmal ansatzweise beherrschst?

> Oder ich setze den Offset dann intern um, aber wie das geht, weiss ich
> jetzt nicht so aus dem Stehgreif...

Dann solltest du dir eine intellektue weniger anspruchsvolle Sprache
nehmen. Visual Basic ist unter Leuten sehr erfolgreich, die
programmieren wollen, aber keine Zeit haben, sich die Grundlagen
anzueignen.

Felix von Leitner

unread,
Dec 3, 2001, 12:41:06 PM12/3/01
to
Thus spake Steffen Conrad (s.co...@aixplain.de):
> aber genau das ist ja das Problem. Ich möchte später auf die einzelnen
> Daten per n->arcs[i].word, n->arcs[i].score etc zugreifen können und da
> sollte ich schon direkt auf dem Anfang der Liste stehen. Oder muss ich
> den gemappten Speicherbereich nochmal einzeln auf die Liste zuweisen?

Kannst du mal eben motivieren, was du mit einer Programmiersprache wie C
tust, wenn du elementare Konzepte wie z.B. den sicheren Umgang mit
Zeigern nicht einmal ansatzweise beherrschst?

> Oder ich setze den Offset dann intern um, aber wie das geht, weiss ich
> jetzt nicht so aus dem Stehgreif...

Dann solltest du dir eine intellektuell weniger anspruchsvolle Sprache
nehmen. Visual Basic ist sehr erfolgreich bei den Leuten, die zwar
programmieren wollen, aber keine Zeit mit dem Lernen von Grundlagen
verschwenden möchten.

Steffen Conrad

unread,
Dec 5, 2001, 9:09:07 AM12/5/01
to
Felix von Leitner wrote:
>
> Kannst du mal eben motivieren, was du mit einer Programmiersprache wie C
> tust, wenn du elementare Konzepte wie z.B. den sicheren Umgang mit
> Zeigern nicht einmal ansatzweise beherrschst?

Eigentlich sollte ich es können, habe eine 3-jährige Ausbildung zum
Mathematisch-technischen Assistenten gemacht und dabei C und C++
gelernt. Wenn man nun aber durch Studium etc. in der letzten Zeit nur
noch mit JAVA etc zu tun hatte, kann es mal vorkommen, dass man ein
wenig eingerostet ist, oder?

> Dann solltest du dir eine intellektuell weniger anspruchsvolle Sprache
> nehmen. Visual Basic ist sehr erfolgreich bei den Leuten, die zwar
> programmieren wollen, aber keine Zeit mit dem Lernen von Grundlagen
> verschwenden möchten.

Und deswegen muss ich mir eigentlich keine Dummheit vorwerfen lassen.
Ich habe hier eine IMO ordentlich formulierte Frage gestellt und habe
ausser Deiner auch ordentlich Antworten erhalten.

Der Sinn der ganzen Sache ist nämlich im Endeffekt, auf _alles_ unnötige
zu verzichten und _nur_ das Feld zu mappen. Das Programm soll später im
embedded-Bereich eingesetzt werden und da kann ich mir unnötigen
Speicherverlust etc. nicht leisten. Momentan ist es vielleicht nur ein
Mappen von zusätzlichen 6 Byte, aber dass wird sich schon bald ändern,
da das Dateiformat umgestellt wird.

BTW - das Problem habe ich im Endeffekt schon alleine gelöst. Das
Problem lag darin, dass ich das Konzept von mmap aus der Manpage nur
teilweise erschliessen konnte und daher hier gefragt habe.
Aber wozu hat man nette Kollegen, die schon ein paar Jahre länger dabei
sind als ich und einem bei Verständnisfragen helfen. Ausserdem habe ich
mal gehört, dass gerade das Usenet für sowas recht geeignet sein soll.
Das die anschliessende Frage, wie ich denn nun an den Feldanfang komme,
vielleicht ein wenig trivial war, ist mir Nachhinein auch aufgefallen.

Vielen Dank an Falk und alle anderen, aber nicht an Dich.

SCNR,

0 new messages