Я взял кусочки кода пользовательского пространства, который я написал, и преобразовал его для работы в пространстве ядра (то есть с помощью kmalloc () и т. Д.), Это не так сложно. Тем не менее, вы ограничены пониманием ядра C, а не пользовательского пространства, которое немного отличается ... особенно с различными стандартными типами int.
Простое связывание с DSO пользовательского пространства невозможно - ядро Linux является монолитным, полностью автономным. Он не использует пользовательское пространство libc, библиотеки или другие биты, как отметили другие.
9/10 раз, вы найдете то, что вам нужно где-то в ядре. Вполне вероятно, что кто-то еще столкнулся с той же потребностью, что и вы, и написал несколько статических функций в каком-то модуле, чтобы делать то, что вы хотите ... просто возьмите их и используйте их повторно.
В случае крипто, как уже говорили другие, просто используйте то, что находится в ядре. Стоит отметить, что вам нужно, чтобы они были включены в kconfig, что может происходить или не происходить в зависимости от того, что пользователь выбирает при его создании. Так что следите за зависимостями и будьте явными, вам, возможно, придется взломать несколько записей в kconfig, которые также выбирают крипто-API, который вы хотите, когда выбран ваш модуль. Делать это может быть немного больно, когда строишь из дерева.
Таким образом, с одной стороны, у нас есть «просто копировать и переименовывать материал, добавляя общий раздув», с другой - «скажите людям, что у них должен быть полный исходный код ядра». Это одна из причуд, которые идут с монолитным ядром.
С микроядром почти все работает в пользовательском пространстве, не нужно беспокоиться о подключении DSO для какого-то драйвера ... это не проблема. Пожалуйста, не принимайте это утверждение как сигнал для перезапуска философии проектирования ядра в комментариях, это не входит в сферу этого вопроса.