Файл как в KLM, так и в пользовательском пространстве

Question

Я помню, как я читал эту концепцию. Я не помню, где. У меня есть файл say file.c, который вместе с другими файлами компилируется вместе с некоторыми другими файлами в качестве библиотеки для использования приложениями.

Теперь предположим, что я скомпилирую тот же файл и построю его с помощью модуля ядра. Следовательно, теперь тот же файл-объект находится как в пространстве пользователя, так и в ядре, и он позволяет мне обращаться к структурам данных ядра без вызова системного вызова. Я имею в виду, что я могу иметь api в библиотеке, с помощью которой приложения могут обращаться к структурам данных ядра без системных вызовов. Я не уверен, могу ли я что-либо записать в ядро ​​(что, я думаю, так невозможно), но чтение некоторых структур данных из ядра было бы в порядке?

Может ли кто-нибудь дать мне более подробную информацию об этом подходе. Я не мог найти ничего в google относительно этого.

Answer 1

Существует два способа сделать это, наиболее распространенным из них является то, что называется устройством символов, а другое - блочным устройством (то есть чем-то вроде диска).

Here's a guide о том, как создавать драйверы, которые регистрируют chardevs.

Answer 2

Я считаю, что это концептуально ошибочный подход, если я не понимаю, о чем вы говорите.

Если вы правильно поняли, вы хотите взять тот же файл и скомпилировать его дважды: один раз в качестве модуля и один раз в качестве пользовательской программы. Затем вы хотите запустить оба из них, чтобы они могли совместно использовать память.

Таким образом, очевидная проблема заключается в том, что, хотя программы исходят из одного и того же исходного кода, они все равно будут существовать как отдельные исполняемые файлы. Модуль не будет его собственным процессом: он будет вызван только при запуске ядра (т. Е. Системных вызовов). Таким образом, это само по себе не позволяет вам избежать системного вызова ерунды.

Лучшее решение зависит от вашей цели: вы просто хотите получить доступ к структурам данных ядра, потому что вам нужно что-то, что вы обычно не можете получить? Или вы обеспокоены производительностью и хотите получить доступ к этим структурам быстрее, чем системный вызов?

Для (1) вы можете создать символьное устройство или файл procfs. Оба они позволяют вашим программам пользовательского пространства добираться до их грязных маленьких пальцев в ядре.

Для (2) вы находитесь в трудном положении, и проблема становится намного более неприятной (и более инстинктивной). Чтобы решить проблему скорости, это зависит от того, какие точные данные вы пытаетесь извлечь.

Помогает ли это?