Включить заголовки ядра правильно [дублировать]
Я считаю, что это то, что вам нужно:
function deepen(o) {
var oo = {}, t, parts, part;
for (var k in o) {
t = oo;
parts = k.split('.');
var key = parts.pop();
while (parts.length) {
part = parts.shift();
t = t[part] = t[part] || {};
}
t[key] = o[k]
}
return oo;
}
Например:
> JSON.stringify(deepen({'ab.cd.e' : 'foo', 'ab.cd.f' : 'bar', 'ab.g' : 'foo2'}))`
"{"ab":{"cd":{"e":"foo","f":"bar"},"g":"foo2"}}"
2 ответа
Ядро не может использовать код пользовательского пространства и должно стоять в одиночестве (т.е. быть полностью автономным, без библиотек), поэтому он не выбирает стандартные заголовки.
Неясно, какую выгоду вы пытаетесь подобрать Заголовки пользовательского пространства. Если есть что-то, что было бы полезно использовать (константы, некоторые макросы, возможно, при условии, что они не вызывают никаких функций в пользовательском пространстве), тогда лучше их дублировать и включать только нужные для ядра части.
Невозможно связать ядро с библиотеками, предназначенными для использования в пользовательском пространстве - даже если они не совершают каких-либо вызовов ОС - потому что среда связи в ядре не может их поднять.
Вместо этого перекомпилируйте любые функции, которые будут использоваться в ядре (при условии, что они не совершают каких-либо вызовов ОС или библиотек - например, malloc - и в этом случае они должны быть изменены в любом случае). Включите их в свою собственную библиотеку, которая будет использоваться в ваших модулях ядра.
Последние версии linux содержат криптографические функции в любом случае, включая различные хэши SHA - возможно, вы можете использовать один из них.
Еще одна идея заключалась бы в том, чтобы перестать пытаться сделать крипто в пространстве ядра и переместить код в пользовательское пространство. Код в области доступа легче писать / отлаживать / поддерживать и т. Д.
Я взял биты кода пространства, который я написал, и преобразовал его в работу в пространстве ядра (т. е. с помощью kmalloc () и т. д.), это не так сложно. Тем не менее, вы ограничены пониманием ядром C, а не пользователем, которое немного отличается .. особенно с различными стандартными типами int.
Простое связывание с пользовательским пространством DSO невозможно - ядро Linux монолитно, полностью автономно. Он не использует библиотеки libc, библиотеки или другие биты, как это отмечали другие.
9/10 раз, вы найдете то, что вам нужно где-то в ядре. Очень вероятно, что кто-то другой столкнулся с той же потребностью, что и у вас, и написал некоторые статические функции в каком-то модуле, чтобы делать то, что вы хотите. Просто возьмите их и повторно используйте их.
В случае криптографии, как говорили другие, просто используйте то, что находится в ядре. Следует отметить, что вам нужно будет включить их в kconfig, который может произойти или не произойти в зависимости от того, что пользователь выбирает при его создании. Итак, следите за зависимостями и будьте ясными, вам может потребоваться взломать несколько записей в kconfig, которые также выбирают криптовый API, который вы хотите, когда выбран ваш модуль.
Итак, с одной стороны, мы «просто копируем и переименовываем материал при добавлении общего раздувания», с другой стороны, вы «говорите людям, что они должен иметь полный исходный код ядра ». Это один из причуд, который поставляется с монолитным ядром.
С Microkernel почти все работает в пользовательском пространстве, никаких проблем с привязкой к DSO для некоторых драйверов ... это не проблема. Пожалуйста, не принимайте это утверждение как подсказку для повторного запуска философии дизайна ядра в комментариях, это не входит в сферу этого вопроса.