2013-03-05 16 views
10

Ich baue gerade ein Modul für den Linux Kernel. Meine Arbeitsrevision ist 3.8-rc3 +. Meine Arbeit führte mich dazu, einige ioctl() Befehle zu implementieren. Wie Sie wissen, sollten meine Befehle einen entsprechenden Fehlercode zurückgeben, um zu beschreiben, was während der Ausführung gescheitert ist. Das scheint ziemlich einfach zu sein, aber ich habe einen Anwendungsfall, für den ich nicht herausfinden kann, welchen Fehlercode ich zurückgeben soll.Welchen Fehlerwert sollte ich verwenden?

Grundsätzlich möchte ich den Benutzer in der Lage sein, kryptografische Schlüssel für ein bestimmtes Gerät festzulegen. Mein Modul speichert die Schlüssel in einem R-B-Baum, indiziert durch die eindeutige Kennung des Geräts (eine Basis int). Wenn das "Ziel" -Gerät bereits einen Eintrag in dem Baum hat, sollte dieser Eintrag aktualisiert werden, andernfalls fügt das Modul einfach einen neu zugewiesenen Eintrag zu dem Baum für dieses Gerät mit dem angeforderten kryptographischen Schlüssel hinzu. Das gesagt ist, können mehrere Dinge auftreten, beim Versuch, den Schlüssel zu setzen:

  • Etwas innerhalb des Moduls kann der Benutzer den Verschlüsselungsschlüssel verwenden aktualisieren: das Modul kehrt EBUSY Fehler.
  • Es gab keine Eingabe und Zuweisung fehlgeschlagen: ENOMEM Fehler.
  • Das Modul gibt seine Ressourcen frei. Der vorhandene Schlüsseleintrag könnte zum Löschen markiert sein (der Eintrag hat ein dying Flag, um dies zu signalisieren): intern verwende ich derzeit EPERM Fehlercode, da der Aufrufer nicht die "Erlaubnis" hat, den Eintrag zu ändern, während er zerstört wird.

Wie gesagt, für den letzteren Fall verwende ich EPERM Fehlercode, aber ich habe einfach das Gefühl, dass es falsch ist und ich weiß nicht, welchen Code Fehler, den ich für diesen Zweck verwendet werden soll. Jeder Rat ist willkommen!

Ich spezifizierte auch Linux-Tag als ioctl() könnte in User-Space-Anwendungen verwendet werden.

EDIT: Nach dem durch Kommentare und Antworten gelesen zu haben, ich glaube, ich es so machen:

  • Wenn das Modul seine Ressourcen freigibt, wird ESHUTDOWN zurückgegeben werden.
  • Wenn nur der Zielschlüssel zerstört wird, während der Rest des Baums immer noch normal ist, wird EACCES verwendet.
+0

Sie wahrscheinlich jeder, EACCES #define können 13/* Zugriff verweigert */ #define EFAULT 14/* Bad-Adresse */ #define EBUSY 16/* Geräte oder besetzt * Ressourcen/ –

+0

@KinjalPatel Ich kann nicht Verwenden Sie "EBUSY", wenn ich den Anwendungsfall 1 von dem Anwendungsfall 3 unterscheiden möchte. "EFAULT" ist nicht geeignet, da der Befehl mit guten Parametern gespeist wurde und kein Segfault verhindert wurde. 'EACCES' könnte den Trick machen, aber ich habe auch das Gefühl, dass es nicht der ursprüngliche Zweck ist. Habe ich recht ? – Rerito

+0

Ja, EACCES wird normalerweise für Benutzerberechtigungen verwendet. aber in Ihrem Fall denke ich, es ist geeignet –

Antwort

3

Wie wäre es mit ESHUTDOWN? (Senden nach dem Beenden des Transportendpunkts nicht möglich)

Eine andere Option ist ENXIO (Kein solches Gerät oder Adresse). Es ist nicht 100% genau, da das Gerät immer noch da ist, aber es vermittelt die Bedeutung des Fehlers (es ist nicht mehr verwendbar).

Eine einfache Wahl ENOTSUP würde (Operation wird nicht unterstützt), aber das klingt eher wie „Methode nicht implementiert“

EPERM besser klingt, aber es ist in der Regel verwendet, um mit „Sie haben keine Berechtigung/Rechte, dies zu tun haben“ anstatt "Sie können das jetzt nicht tun".

ESTALE (veraltete Datei-Handle) wäre nett, aber es ist NFS verwandt.

+0

Ich vermisste 'ESHUTDOWN', es ist sehr explizit, obwohl die Beschreibung für mich irreführend scheint. Wie auch immer, ich denke, das ist die schönste Lösung. Danke, dass du darauf hingewiesen hast. – Rerito

Verwandte Themen