Вам будет очень трудно добавить новый интерфейс в / proc /. Разработчики ядра недовольны тем, что он стал местом сброса различных интерфейсов, и, если вы на самом деле не вносите какие-либо изменения в процессы с помощью / proc / pid /, я думаю, у вас не получится убедить сообщество ядра принять его.
Файл устройства в / dev / может быть приемлем, даже для модулей, которые на самом деле не являются драйверами устройств. (например, / dev / kvm, / dev / pts, / dev / ecryptfs, / dev / fuse, / dev / kmsg, / dev / ptmx и т. д.) Однако файлы устройства слишком часто проще манипулировать с помощью ioctl ( ), и я думаю, что вы правы, если можете этого избежать.
Текущая тенденция в кругах ядра - это sysfs или пользовательские файловые системы. Подход sysfs основан на семантике одно значение на файл, предназначенной для манипулирования с помощью echo и cat. Это замечательно для пользователей, если это работает для вас. Пользовательские файловые системы позволяют вам писать очень специфичные двоичные интерфейсы, а fs / libfs.c должен помочь вам написать собственную файловую систему для ваших собственных нужд. (Я не знаю никого, кто использовал configfs, но я всегда думал, что это выглядело аккуратно. Может, это подойдет вашему модулю?)