Зарезервировать фиксированную область оперативной памяти в качестве блочного устройства (с заданным начальным физическим адресом)


11

Было много вопросов о RAM-дисках, и мне известны ramfs и tmpfs, которые позволяют использовать ram в качестве блочного устройства. Однако меня интересует использование фиксированного диапазона адресов памяти в качестве блочного устройства.

Это связано с необходимостью использования энергонезависимой оперативной памяти, доступной в моей системе. У меня есть 6 ГБ оперативной памяти и 8 ГБ энергонезависимой памяти. Вывод / proc / iomem дает мне следующее

100000000-17fffffff: ОЗУ системы

180000000-37fffffff: зарезервировано

Здесь область от 6 до 14 ГБ соответствует области энергонезависимой памяти, которая помечена картой памяти E820 BIOS как зарезервированная. Мое главное намерение - использовать этот NVRAM в качестве блочного устройства в Linux. Это полезно для тестирования систем NVRAM. Существует ли какая-либо команда linux, которая позволила бы мне использовать этот регион в качестве блочного устройства, или мне нужно написать собственный драйвер устройства ядра, чтобы облегчить то же самое?


2
Просто любопытно, зачем тебе это делать?
mtak

Он предоставляет простой способ тестирования файловых систем, разработанных для энергонезависимой оперативной памяти в Linux.
qstack

Ответы:


2

Я не эксперт по драйверам устройств, но вот несколько советов для ваших исследований и разработок:

  1. если память помечена как «зарезервированная», ОС не может ее коснуться; вам нужно будет найти способ сделать так, чтобы BIOS помечал его как доступный для ОС, или используйте прямые низкоуровневые ioctl для управления им.
  2. если бы Linux мог видеть память, у вас все равно не было бы простого способа помешать Linux использовать ее как любой другой блок оперативной памяти; Можно попытаться попытаться пометить такую ​​оперативную память как «плохую», а затем модифицировать ядро, чтобы оно по-прежнему использовалось специально (пожалуйста, ознакомьтесь с документацией ядра по этому поводу, оно сильно изменилось с тех пор, как я в последний раз взламывал его, и оно развивается) на большой скорости)
  3. Рассматривая вышесказанное как предварительное (и не окончательное и не исчерпывающее) технико-экономическое обоснование, я бы сказал, что написание вашего драйвера блочного устройства ramdisk является наиболее разумным вариантом в вашем случае, и, возможно, вам следует добавить его обратно в ядро ​​Linux и / или объединиться с люди уже пробуют это (возможно, лучшее место для этого вопроса - список рассылки ядра Linux , если вы еще не публиковали там)

Некоторые другие соответствующие источники:


1

До введения tmpfs/ initramfsтам ramdiskиспользовалась для загрузки initrdизображений заранее заданная блочная аппаратура фиксированного размера, я думаю, смежная, по крайней мере, в более ранних реализациях.

Сам драйвер блока не имеет параметров для адреса памяти, только размер, но ядро, используемое для загрузки образов initrd по заранее определенному адресу (по конфигурации), так что заглядывание в код ядра main / init может помочь (я хотел бы удивитесь, если ramdisk больше не поддерживается для initrd, но поскольку initramfs существует, много лет назад никогда больше не использовал ramdisk ).

Источник водитель водителей / блок / rd.c , если я вижу , правильно сейчас драйверы / блок / brd.c .

Еще, в поисках ramdisk я нашел реализацию, которая выглядит интересно:

Диск в ОЗУ - игра с блочными драйверами

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.