2013-03-05 19 views
10

Aktualnie buduję moduł dla jądra Linux. Moja robocza wersja to 3.8-rc3 +. Moja praca doprowadziła mnie do wdrożenia niektórych poleceń ioctl(). Jak wiesz, moje polecenia powinny zwracać odpowiedni kod błędu, aby opisać, co poszło nie tak podczas wykonywania. Wydaje się to dość proste, ale mam przypadek użycia, dla którego nie mogę dowiedzieć się, który kod błędu powinienem zwrócić.Którą wartość błędu należy użyć?

Zasadniczo chcę, aby użytkownik mógł ustawić klucze kryptograficzne dla danego urządzenia. Mój moduł przechowuje klucze w drzewie R-B, indeksowane przez unikalny identyfikator urządzenia (podstawowy int). Jeśli urządzenie "docelowe" ma już wpis w drzewie, to wpis ten powinien zostać zaktualizowany, w przeciwnym razie moduł po prostu doda nowo przydzielony wpis do drzewa dla tego urządzenia, z żądanym kluczem kryptograficznym. Powiedział, że wiele rzeczy może wystąpić podczas próby ustawić klucz:

  • Coś wewnątrz modułu może być przy użyciu klucza kryptograficznego użytkownik chce zaktualizować: moduł zwraca EBUSY błąd.
  • Brak wpisu i alokacji nie powiodło się: błąd ENOMEM.
  • Moduł zwalnia swoje zasoby. Istniejący wpis klucza może być oznaczony do usunięcia (wpis ma flagę dying, aby zasygnalizować to): wewnętrznie używam obecnie kodu błędu EPERM, ponieważ osoba dzwoniąca nie ma "uprawnień" do zmiany pozycji podczas jej niszczenia.

Jak powiedziałem, na tym ostatnim przypadku, używam EPERM kod błędu, ale mam wrażenie, że to jest złe i nie wiem który kod błędu należy używać do tego celu. Każda rada jest mile widziany!

Podałem także znacznik linux jako ioctl() może być używany w aplikacjach przestrzeni użytkownika.

EDIT: Po przeczytaniu poprzez komentarze i odpowiedzi, myślę, że zrobię to w ten sposób:

  • Gdy moduł jest zwolnienie jego zasobów, zostanie zwrócony ESHUTDOWN.
  • Gdy tylko klucz docelowy jest niszczony, podczas gdy reszta drzewa jest nadal przy zdrowych zmysłach, zostanie użyty EACCES.
+0

prawdopodobnie można użyć dowolnego, #define EACCES 13/* Permission denied */#define EFAULT 14/* zły adres */ #define EBUSY 16/* Urządzenie lub zasobów zajęty */ –

+0

@KinjalPatel nie mogę użyj 'EBUSY', jeśli chcę rozróżnić przypadek użycia 1 od przypadku użycia 3.' EFAULT' nie jest odpowiedni, ponieważ polecenie zostało podane z dobrymi parametrami i nie udało się zapobiec jego wystąpieniu. "EACCES" może załatwić sprawę, ale mam też wrażenie, że to nie jest jej pierwotny cel. Czy mam rację ? – Rerito

+0

tak, EACCES jest generalnie używany dla pozwolenia użytkownika. ale w twoim przypadku myślę, że jest odpowiedni –

Odpowiedz

3

Co powiecie na ESHUTDOWN? (Nie można wysłać po wyłączeniu punktu końcowego transportu)

Inną opcją jest ENXIO (Brak takiego urządzenia lub adresu). Nie jest w 100% dokładne, ponieważ urządzenie nadal istnieje, ale przekazuje znaczenie tego błędu (nie można go już użyć).

Prostym rozwiązaniem byłoby ENOTSUP (operacja nie jest obsługiwana), ale to brzmi bardziej jak „metody nie realizowany”

EPERM brzmi lepiej, ale to zwykle używane z „nie masz uprawnień/prawa, aby to zrobić” zamiast "nie możesz tego teraz zrobić".

ESTALE (Stale plik uchwyt) byłoby miło, ale jest związany z NFS.

+0

Brakowało mi "ESHUTDOWN", jest to bardzo wyraźne, mimo że opis wydaje mi się mylący. W każdym razie myślę, że to najmilsze rozwiązanie. Dziękuję za wskazanie tego. – Rerito

Powiązane problemy