В настоящее время я создаю модуль для ядра Linux. Моя рабочая ревизия - 3.8-rc3 +. Моя работа привела меня к выполнению команд ioctl()
. Как вы знаете, мои команды должны возвращать соответствующий код ошибки, чтобы описать, что пошло не так во время выполнения. Это кажется довольно простым, но у меня есть прецедент, для которого я не могу понять, какой код ошибки я должен вернуть.Какое значение ошибки следует использовать?
В принципе, я хочу, чтобы пользователь мог установить криптографические ключи для данного устройства. Мой модуль хранит ключи в дереве R-B, индексируется уникальным идентификатором устройств (базовый int
). Если «целевое» устройство уже имеет запись в дереве, то эта запись должна быть обновлена, иначе модуль просто добавляет новую выделенную запись в дерево для этого устройства с запрошенным криптографическим ключом. Это сказало, множество вещей может произойти при попытке установить ключ:
- Что-то внутри модуля может быть с использованием криптографического ключа пользователь хочет обновить: модуль возвращает
EBUSY
ошибку. - Не удалось выполнить вход и выделение:
ENOMEM
Ошибка. - Модуль освобождает свои ресурсы. Существующая запись может быть помечена для удаления (для записи это имеет флаг
dying
): внутренне я в настоящее время использую код ошибкиEPERM
, поскольку вызывающий абонент не имеет «разрешения» для изменения записи во время ее уничтожения.
Как я уже говорил, для последнего случая, я использую EPERM
код ошибки, но у меня есть ощущение, что это неправильно, и я не знаю, какой код ошибки следует использовать для этой цели. Любые советы приветствуются!
Я также указал тег linux, поскольку ioctl()
может использоваться в пользовательских приложениях.
EDIT: После того, как прочитав комментарии и ответы, я думаю, что я буду делать это так:
- Когда модуль высвобождает свои ресурсы,
ESHUTDOWN
будут возвращены. - Когда уничтожается только целевая клавиша, в то время как остальная часть дерева по-прежнему нормальная, будет использоваться
EACCES
.
вы, вероятно, может использовать любой из, #define EACCES 13/* Permission Denied */#define EFAULT 14/* Неверный адрес */#define EBUSY 16/* Устройство или ресурс занят */ –
@KinjalPatel я не могу используйте «EBUSY», если я хочу различить случай использования 1 из варианта использования 3. «EFAULT» не подходит, поскольку команда была снабжена хорошими параметрами, и segfault не было предотвращено. «EACCES» мог сделать трюк, но у меня также есть чувство, что это не его первоначальная цель. Я прав ? – Rerito
Да, EACCES обычно используется для разрешения пользователя. но в вашем случае я думаю, что его подходящий –