2013-03-05 3 views
10

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

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

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

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

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

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

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

вы, вероятно, может использовать любой из, #define EACCES 13/* Permission Denied */#define EFAULT 14/* Неверный адрес */#define EBUSY 16/* Устройство или ресурс занят */ –

+0

@KinjalPatel я не могу используйте «EBUSY», если я хочу различить случай использования 1 из варианта использования 3. «EFAULT» не подходит, поскольку команда была снабжена хорошими параметрами, и segfault не было предотвращено. «EACCES» мог сделать трюк, но у меня также есть чувство, что это не его первоначальная цель. Я прав ? – Rerito

+0

Да, EACCES обычно используется для разрешения пользователя. но в вашем случае я думаю, что его подходящий –

ответ

3

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

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

Простой выбор будет ENOTSUP (операция не поддерживается), но это звучит как «метод не реализован»

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

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

+0

Я пропустил 'ESHUTDOWN', это очень ясно, несмотря на то, что описание кажется мне вводящим в заблуждение. Во всяком случае, я думаю, что это самое приятное решение. Спасибо, что указали это. – Rerito

Смежные вопросы