Какое значение ошибки следует использовать?

В настоящее время я создаю модуль для ядра Linux. Моя рабочая ревизия - 3.8-rc3+. Моя работа привела меня к выполнению некоторых команд ioctl(). Как вы знаете, мои команды должны возвращать соответствующий код ошибки, чтобы описать, что пошло не так во время выполнения. Это кажется довольно простым, но у меня есть прецедент, для которого я не могу понять, какой код ошибки я должен вернуть.

В принципе, я хочу, чтобы пользователь мог установить криптографические ключи для данного устройства. Мой модуль хранит ключи в дереве R-B, индексируется уникальным идентификатором устройств (базовый int). Если "целевое" устройство уже имеет запись в дереве, то эта запись должна быть обновлена, иначе модуль просто добавляет новую выделенную запись в дерево для этого устройства с запрошенным криптографическим ключом. Тем не менее, при попытке установить ключ может произойти несколько вещей:

  • Что-то внутри модуля может использовать криптографический ключ, который пользователь хочет обновить: модуль возвращает ошибку EBUSY.
  • Ошибка ввода и размещения не удалась: ENOMEM ошибка.
  • Модуль освобождает свои ресурсы. Существующая запись ключа может быть помечена для удаления (запись имеет флаг dying, чтобы сигнализировать об этом): внутренне я в настоящее время использую код ошибки EPERM, поскольку вызывающий объект не имеет "разрешения" для изменения записи при ее уничтожении.

Как я уже сказал, для последнего случая я использую код ошибки EPERM, но у меня такое чувство, что я ошибаюсь, и я не знаю, какой код ошибки я должен использовать для этой цели. Любые советы приветствуются!

Я также указал тег linux, поскольку ioctl() может использоваться в пользовательских приложениях.

EDIT: прочитав комментарии и ответы, я думаю, что сделаю так:

  • Когда модуль освобождает свои ресурсы, возвращается ESHUTDOWN.
  • Когда уничтожается только целевой ключ, а остальная часть дерево по-прежнему нормальное, EACCES будет использоваться.

Ответ 1

Как насчет ESHUTDOWN? (Не удается отправить после выключения конечной точки транспортного средства)

Другим вариантом является ENXIO (Нет такого устройства или адреса). Это не на 100% точно, поскольку устройство все еще существует, но оно передает значение ошибки (оно больше не используется).

Простым выбором будет ENOTSUP (операция не поддерживается), но это больше похоже на "не реализованный метод"

EPERM звучит лучше, но обычно используется с "у вас нет прав/прав для этого", а не "вы не можете сделать это прямо сейчас".

ESTALE (Stale file handle) было бы неплохо, но это связано с NFS.