2012-04-03 3 views
1

Ich bekomme nicht viel Informationen über den neuen Systemaufruf name_to_handle_at() und open_to_handle_at(). Kann mir hier jemand helfen?Logik von name_to_handle_at()

Danke

Ein Edit. Gerade eben habe ich

http://comments.gmane.org/gmane.linux.man/2158

+0

können Sie uns einen Link oder Zitat um den Kontext zu zeigen, wo es verwendet wird? – cctan

+0

Es ist eine "neue" Linux-Kernel-Funktion, die sich mit Datei-Handles beschäftigt. Niemand spricht wirklich viel darüber. Ich würde es persönlich lieben, wenn ein Kernel-Entwickler oder was auch immer dies nicht ausführlich beantworten könnte. –

Antwort

0

Ich würde geneigt sein, anzunehmen, dass diese Funktionen benötigt werden, einige oder alle der *at() Funktionen POSIX 2008 wie openat() hinzugefügt zu unterstützen:

#include <fcntl.h> 

int openat(int fd, const char *path, int oflag, ...); 

Die Funktion openat() muss der Funktion open() entsprechen, außer in dem Fall, in dem path einen relativen Pfad angibt. In diesem Fall wird die zu öffnende Datei relativ zu dem Verzeichnis bestimmt, das dem Dateideskriptor fd anstelle des aktuellen Arbeitsverzeichnisses zugeordnet ist. Wenn der Dateideskriptor ohne O_SEARCH geöffnet wurde, sollte die Funktion prüfen, ob Verzeichnissuchen mit den aktuellen Berechtigungen des dem Dateideskriptor zugrunde liegenden Verzeichnisses erlaubt sind. Wenn der Dateideskriptor mit O_SEARCH geöffnet wurde, darf die Funktion die Prüfung nicht durchführen.

ähnliche Funktionen sind:

2

Diese Funktionen sind nützlich für die User-Space-Server zu schreiben.

Wenn Sie zum Beispiel das NFS-Protokoll implementieren, das nicht das Konzept 'open' oder einen Dateideskriptor hat, sondern stattdessen auf eine persistente Dateikennung, kann die Funktion 'name_to_handle_at' verwendet werden, um dieses persistente Handle zu generieren tragbarer Weg.

Es wird dann an den Client gesendet, der es zu einem späteren Zeitpunkt an den Server zurückgibt. Der Server kann dann open_to_handle_at verwenden, um den Vorgang auszuführen.

Man könnte fragen, wie das besser ist, als einfach den vollständigen Pfadnamen zwischen Client und Server zu senden. Eine Reihe von Optionen:

  • Das Dateisystem kann intern (kompakteren) Darstellungen verwenden anstelle des Dateinamens (zB auf Basis von inode).
  • Beim Übergang vom Handle zum Dateideskriptor müssen möglicherweise weniger Arbeit getan werden. (Nicht mehr Path Traversal)
  • In dem Szenario oben angegebenen Ressourcenverbrauch auf dem Server reduziert wird (keine Notwendigkeit Spur offener Dateien auf der Serverseite zu halten)