когда пользователь обращается к отображённой памяти, вызов mmap уже давно закончился и не может "отловить это изменение". Ты имел в виду подсистему виртуальной памяти?
jcmvbkbc, хз, я не знаю работы mmap. знаю лишь то что изменения в памяти куда с помощью mmap замаплен файл, вызовет каким-либо запрос на изменения файла.
А если файл тем временем удалили? Или переименовали? Или удалили и создали другой файл с таким же именем на его месте?
файл, открытый на запись, заблокирован. точнее заблокирована inode с содержимым, а вот имя файла, насколь знаю, можно изменить. но это совсем не в тему.
Т.е., я правильно понимаю, что по-твоему /dev/mem работает только пока он в /dev, а если его перенести в какое-нибудь другое место, то он работать перестанет?
я сталкивался с ним только по стандартному пути /dev/mem
можно ли еще где создать не знаю. да и в контексте вопроса сие не имеет значения.
в любом случае это не будет прямым изменением памяти.
Нет, не потребует. Потому что проверкой доступа занимается вызов open, которым файл открывают.
полностью согласен.
а если есть хук в mmap под /dev/mem или еще где, это потребует в хуке кода спец.кода для обработки доступа.
Я выше приводил ссылки в код ядра реализующий mmap для /dev/mem, в чём ты конкретно сомневаешься, я не понял?
код, реализующий mmap под /dev/mem, не приводил :)
inneks, в этой виртуальной машине подключаешь лайв-образ ubuntu. загружаешься в него. подключаешь носитель смотришь что с ним случилось.
предположу что vdi не правильно ужался :-/
Это не "ты привёл цепочку действий", это ты какую-то бредовую фантазию привёл, без каких либо документальных потверждений.
где здесь бредовость ?? :)
стандартная цепочка действий работы с файлом (про хук чуть ниже, считаем что его нет).
mmap работает с файлом, т.е. формирует файловые операции, дальше цепочка обработки файла станадартна. в каком месте бредовость ??
у тебя рассказано как работает mmap, это имеет смысл если для /dev/mem написан хук, позволяющий исключить все файловые операции и напрямую записывать в память. но это потребует наличие в хуке кода обработки доступов пользователя к /dev/mem. сильно сомневаюсь что такой хук будет внедрен, смысл в нем ??
jcmvbkbc, не все знаю, чего в этом криповатого ??
Не погромист, с системными функциями линукс не ковырялся.
Цепочку действий для записи значения в память с помощью спец.файла /dev/mem я привел чуть выше.
Приведи свою.
Я сильно сомневаюсь что в функции mmap есть хук под файл /dev/mem, позволяющий мапить /dev/mem в память с совпадающими диапазонами и тем самым записывать значение напрямую в ram, без указанной цепочки
Nitaki58, если есть познания в програмировании (скорей всего в С, но сейчас в ядро потихоньку впускают rust), то разбираешься с железом.
ищешь уже работающие аналогичные драйвера в завалах исходников kernel. разбираешься как они работают, скорее всего они формируют стандартные интерфейсы управления в соответствующих подпапках /sys.
к примеру /sys/class/leds для светодиодиков, у меня там три ссылки на устройства светодиодиков клавиатуры.
переделываешь под свой ноутбук. компилируешь, тестируешь, допиливаешь и выкладываешь на тест.
после теста несколькими сторонними пользователями формируешь патч на внедрение твоей работы в ядро линукса.
имхо так будет сложно, долго, но правильно :)
книг статей навалом. тот же сборник Можете подсказать практичный список литературы по разработке драйверов для linux и вообще по работе в ядре? от jcmvbkbc
jcmvbkbc, неа, ваапче не так :)
mmap отображает фал на произвольную память, котрую ему выдал менджер памяти. ты записываешь в эту область, mmap отлавливает это изменение и формирует файловый запрос на запись. запрос получает драйвер VFS разбирает путь, выявляет подстрочку /dev и направляет его в драйвер udev ответственный за этот путь. udev перенаправляет запрос в драйвер, ответственный за /dev/mem, и только он разбирает файловый запрос и пишет напрямую в указанный адрес физической памяти.
это конечно докапывание до тонкостей, но вот так :)
jcmvbkbc, чет костыль какойто :) из мана по ioperm
ЗАМЕЧАНИЯ
Libc5 рассматривает данную функцию как системный вызов, и поэтому в есть ее прототип. В Glibc1 этого прототипа нет. В Glibc2, в и в этот прототип есть. Не используйте второй вариант, он существует только в версии i386.
ну а /dev/mem "не прямой путь" :) в остальном согласен.
Roman_sz, предположить можно что угодно.
точно знают только инженеры, создавшие/работающие с этой схемой :)
кондер, судя по обрывку схемы, стоит как шумоподавляющий на питании, разница в структуре не сыграет роли.
если есть сомнения ставь бОльшую емкость и напряжение.
xotkot, ну ты блин даешь :) в ролинге архив пакетов аккурат нужон как манна небесная.
ибо при любом косяке, появившемся в новом пакет при частом ролинге, есть возможность откатиться на старый пакет, авось в нем косяк еще не вмерджили в мейнстрим...
Tm, у тебя корень залочен запущенными программами и сервисами.
освободить раздел с корнем от привязок можно, но весьма геморно и требует познаний и ковыряний.
проще запустить gparted с какого-нить стороннего носителя. тогда корневой раздел будет свободен от залочиваний и с ним можно сделать все что угодно.
Drno, мда выделять под корень 20 гб на 2 тб носителе это конечно перегиб мудреностей :)
растяни на 200+ гб, не жопься, вдруг чего еще тяжелого наустанавливаешь.
UlarSur, трансляция кода из одной процессорной архитектуры в другую вещчъ тяжелая. и это надо делать на каждую процессорную команду...
в эльбрусе помнится есть какието аппаратные приблуды для трансляции, но не в арме.
и тем более не для виндовых програмулин.
quemu может запускать виртуалку с x86 на армах.
минус один - жуткое просадка скорости. "частоту" процессора можешь смело делить на 10 или больше.
может просто отказаться от виндовс. этот костыль ржавыми гвоздями к некрософту прибит.
jcmvbkbc, хз, я не знаю работы mmap. знаю лишь то что изменения в памяти куда с помощью mmap замаплен файл, вызовет каким-либо запрос на изменения файла.
файл, открытый на запись, заблокирован. точнее заблокирована inode с содержимым, а вот имя файла, насколь знаю, можно изменить. но это совсем не в тему.
я сталкивался с ним только по стандартному пути /dev/mem
можно ли еще где создать не знаю. да и в контексте вопроса сие не имеет значения.
в любом случае это не будет прямым изменением памяти.
полностью согласен.
а если есть хук в mmap под /dev/mem или еще где, это потребует в хуке кода спец.кода для обработки доступа.
код, реализующий mmap под /dev/mem, не приводил :)