Устройства Mtd в ноутбуке что это такое
Обновлено: 04.07.2024
В этой статье показано, как разработчики ядра и приложений (на C) могут использовать устройства MTD в Linux.
MTD (Memory Technology Devices) – это микросхемы флэш-памяти на основе NAND/NOR, которые используются для хранения энергонезависимых данных, таких как загрузочные образы и конфигурации. Предупреждаем читателей, чтобы их не путали с USB-накопителями, SD-картами и т. д., которые также называются флэш-устройствами, но не являются устройствами MTD. Последние обычно находятся на макетных платах, используются для хранения загрузчиков, ОС и т. д.
Несмотря на то, что устройства MTD предназначены для хранения данных, они отличаются от жестких дисков и оперативной памяти в нескольких аспектах. Самая большая разница заключается в том, что в то время как сектора жесткого диска являются перезаписываемыми, секторы устройства MTD должны быть стерты перед перезаписью, поэтому их чаще называют стирающими блоками. Во-вторых, сектора жесткого диска можно перезаписывать несколько раз, не изнашивая аппаратное обеспечение, но секторы устройства MTD имеют ограниченный срок службы и не могут быть использованы примерно после 10^3-10^5 операций стирания. Изношенные блоки стирания называются поврежденными блоками, и программное обеспечение должно следить за тем, чтобы такие блоки не использовались.
Как и жесткие диски, устройства MTD могут быть разбиты на разделы и, следовательно, могут работать как независимые устройства. В системе с одним или несколькими устройствами MTD информацию об устройствах и разделах можно получить из файла /proc/mtd. Типичный файл /proc/mtd выглядит следующим образом:
Разделенное устройство MTD можно изобразить, как показано на рисунке 1, на котором показано соотношение между устройством MTD, разделом и сектором.
Рисунок 1: Устройство MTD
Как уже было сказано, операции записи MTD отличаются от обычных устройств хранения. Поэтому, прежде чем двигаться дальше, давайте разберемся, как происходят операции записи на устройствах MTD. На рис. 2 показан типичный случай записи.
Рисунок 2: Операция записи MTD
Самая левая часть показывает сектор, в конце которого есть данные. Остальная часть сектора не записывалась с момента последнего стирания. Пользователь хочет записать «новые данные 1» в этот сектор по смещению 0. Поскольку эта часть сектора уже стерта, она готова к записи, поэтому «новые данные 1» могут быть записаны непосредственно в сектор. Позже пользователь может захотеть записать «новые данные 2» снова по смещению 0. Для этого сектор необходимо стереть. Так как сектор нужно стереть целиком, «старые данные» необходимо сохранить во временном буфере. После стирания всего сектора «новые данные 2» и «старые данные» должны быть записаны с соответствующими смещениями.
Эта процедура является причиной того, что существуют специальные файловые системы для устройств MTD, такие как JFFS2 и YAFFFS, и уровни флэш-трансляции (FTL), такие как NFTL, INFTL и т. д. Эти FTL и файловые системы уделяют особое внимание свойствам устройства MTD, чтобы скрыть сложность от пользователя.
В первом следующем разделе мы рассмотрим, как получать доступ, читать/записывать и стирать устройства MTD из приложений Linux. Второй раздел описывает то же самое в пространстве ядра, так что эта статья может быть полезна как разработчикам приложений, так и разработчикам ядра.
Доступ к MTD из приложений
Пользователь должен знать раздел устройства для работы, который можно найти в /proc/mtd, как показано ранее. Если пользователи хотят работать с разделом userdata, они должны использовать устройство /dev/mtd5.
Первое, что нужно сделать, это получить информацию об устройстве МПД. Используйте команду MEMGETINFO ioctl следующим образом:
Для краткости обработка ошибок опущена. Структура mtd_info_t используется с командой MEMGETINFO. Тип MTD может быть MTD_ABSENT, MTD_RAM, MTD_ROM, MTD_NAND, MTD_NOR и т. д., которые определены в заголовочном файле mtd/mtd-abi.h. mtd_info.size указывает размер всего устройства (т. е. раздела в данном случае). Наконец, mtd_info.erasesize указывает размер сектора. Во время операции стирания это минимальный размер, который можно стереть, как мы увидим позже.
Чтение устройств MTD аналогично обычным устройствам:
Операция записи может быть выполнена таким же образом, при условии, что сектор был предварительно стерт. Наконец, мы подошли к операции стирания. Вот пример стирания раздела по секторам:
После этой операции стирания все сектора устройства доступны для записи. Обратите внимание на использование MEMUNLOCK перед MEMERASE, что необходимо для разрешения операции стирания.
Доступ к MTD из пространства ядра
В этом разделе будут повторяться функции, описанные в предыдущем разделе, но в пространстве ядра.Для этого нужен отдельный раздел, так как операция стирания здесь более сложная — операция стирания может приостановить работу, и поэтому программист ядра должен дождаться завершения операции. Это относится и к приложениям, но о спящем режиме прозрачно заботится планировщик.
Как объяснялось ранее, первой информацией MTD является структура mtd_info. Это получается путем перебора всех зарегистрированных устройств MTD:
Приведенный выше модуль ядра ищет раздел «userdata». Функция get_mtd_device() при вызове с первым аргументом NULL возвращает устройство MTD, связанное с младшим номером, указанным во втором аргументе. При успешном поиске увеличивается счетчик ссылок устройства. Вот почему перед выходом необходимо вызвать функцию put_mtd_device() для сброса (уменьшения) счетчика ссылок.
Кроме того, модуль использует флаг MTD_ABSENT (который также доступен для приложений). Эта проверка необходима для правильной работы с некоторыми драйверами зондирующих устройств, используемыми для выделения замещающих устройств MTD в системах с сокетами или съемными носителями.
После извлечения структуры mtd_info чтение становится относительно простым:
Второй аргумент функции чтения указывает смещение чтения, а третий - длину для чтения. Обратите внимание, что операция чтения тоже может заснуть, и поэтому ее нельзя выполнять в контексте прерывания. Операция записи может быть выполнена следующим образом (при условии, что сектор был предварительно стерт):
Как упоминалось ранее, операции чтения, записи и стирания могут приостанавливаться. Поэтому код ядра должен дождаться завершения операции. Вот пример стирания раздела и ожидания завершения операции:
Функция erase_partition() выполняет итерацию по всем секторам и стирает их с помощью erase_sector() . В основе Erase_sector() лежит вызов mtd_info->erase, который (как упоминалось ранее) может спать. Таким образом, erase_sector() подготавливает очередь ожидания и заголовок очереди ожидания.
После вызова mtd_info->erase функция готовится освободить ЦП (предполагая, что mtd_info->erase перейдет в спящий режим), изменив состояние задачи на TASK_UNINTERRUPTIBLE и добавив себя в начало очереди ожидания. Перед освобождением ЦП он проверяет, выполнено ли стирание с помощью флага ei.state. Если стирание выполнено успешно, этот флаг будет установлен на MTD_ERASE_DONE .
Если операция стирания не завершена, задача освобождает ЦП, вызывая schedule() . Позже, когда операция стирания завершена, драйвер вызывает функцию обратного вызова, предоставленную в ei.callback. Здесь задача пробуждается сама по себе, затем удаляется из очереди ожидания, меняет состояние задачи на TASK_RUNNING и, наконец, возвращается функция erase_sector().
Устройства MTD имеют гораздо больше функций, которые могут использоваться разработчиками приложений. ECC (коды исправления ошибок) и OOB (внеполосные) данные являются одними из них. Фреймворк MTD интегрирован в ядро Linux — поэтому он очень упрощает работу с устройствами MTD, как мы видели в этой статье.
Недавно я имел удовольствие участвовать в вебинаре с Микелем Драгичи, главным инженером Zimperium, и Дж. Т. Китингом, нашим старшим вице-президентом по маркетингу, на котором мы говорили о различиях между защитой от мобильных угроз (MTD) и управлением мобильными устройствами. (МДМ).
Веб-семинар «Другая половина уравнения: почему агентства, заботящиеся о безопасности, объединяют UEM и MTD» на самом деле возник из-за путаницы, которую я наблюдал у некоторых организаций в государственном секторе относительно ролей и различий между MDM и MTD.
Чтобы просмотреть вебинар полностью, нажмите здесь .
На протяжении многих лет мы наблюдали равенство между тем, как используются ноутбуки/настольные компьютеры и мобильные устройства, и содержащейся в них информацией/данными. Однако в то время как подавляющее большинство ноутбуков и настольных компьютеров защищены предприятиями (вы бы вышли из офиса без какой-либо защиты на своем ноутбуке), этого нельзя сказать о мобильных устройствах.
Подобно диспетчеру конфигурации для ноутбуков и настольных компьютеров, предприятия могут использовать MDM для централизованного управления мобильными устройствами.
MDM — это инструмент управления. Он позволяет совместимым устройствам получать доступ к корпоративной электронной почте, приложениям через корпоративный магазин приложений и данным, а также защищает передачу данных между мобильным устройством и корпоративной сетью.
Решения MTD обнаруживают и предотвращают атаки на мобильные устройства, сети, фишинг и вредоносные приложения. В качестве примера этих типов угроз мы наблюдаем увеличение и всплеск мобильных взломов и взломов во время COVID. И мы не одиноки:
- Только за последнюю неделю Google ежедневно отслеживал более 18 миллионов вредоносных программ и фишинговых писем, связанных с мошенничеством в связи с COVID-19. Это помимо более чем 240 миллионов спам-сообщений, которые он видит ежедневно, связанных с новым коронавирусом; и
- Wall Street Journal предупредил о значительном росте числа схем фишинга, робоколлинга и «смишинга» (мошенничества с текстовыми сообщениями, отправляемыми на ваш телефон), включая проверки стимулов, возмещение расходов авиакомпаниями, благотворительность, штрафы за нарушение правил социального дистанцирования, «обязательные» действия. Тесты на готовность к COVID-19, недоказанные методы лечения и продажа востребованных товаров, таких как маски или термометры.
Управление MDM; МПД предотвращают и обнаруживают.
И Gartner, и Национальный институт стандартов и технологий (NIST) признают важность MTD для защиты конечных точек.
Вместе лучше
MITRE ATT&CK – это общедоступная база знаний о тактике и методах противников, основанная на реальных наблюдениях. База знаний ATT&CK используется в качестве основы для разработки конкретных моделей угроз и методологий в частном секторе, в правительстве, а также в сообществе продуктов и услуг кибербезопасности.
Сами по себе MDM не учитывают эти тактики и методы (опять же, MDM не предназначены для этого).
Вместе с МПД это гораздо лучшая защитная поза.
Подробнее
Чтобы просмотреть вебинар полностью, нажмите здесь . Если вы хотите узнать больше о реальных мобильных атаках и о том, что предприятия и агентства могут сделать, чтобы защитить себя, загрузите наш технический документ «Анатомия мобильных атак» . Чтобы узнать больше, свяжитесь с нами. Мы здесь, чтобы помочь.
Автор: Джим Ковач
Вице-президент по государственному сектору с более чем 20-летним опытом поддержки государственного сектора, включая министерство обороны федерального правительства, гражданские и разведывательные агентства, а также государственные и местные органы власти. Вне офиса я гуляю со своими щенками, наслаждаюсь активным отдыхом, раздражаю своих взрослых детей и провожу слишком много времени в магазине Lowe's, занимаясь своими делами.
20 декабря 2021 г. Android
Защита ваших бизнес-данных — это не только защита ваших офисных компьютеров и сетей. Особенно сейчас, когда внедрение удаленных и гибридных рабочих сред имеет решающее значение для выживания бизнеса, вам необходимо установить цифровые барьеры вокруг мобильных устройств вашей компании, чтобы блокировать вредоносное ПО и другие угрозы. Вот как это сделать с помощью инструментов обнаружения мобильных угроз (MTD).
MTD и обнаружение вредоносных программ
Решения для обнаружения мобильных угроз предотвращают сетевые атаки и заражение вредоносным ПО на мобильных устройствах, таких как смартфоны, планшеты и ноутбуки. Поскольку большинство вредоносных программ искусно маскируются под легитимные приложения, ключом к их обнаружению и защите от них является распознавание нестандартных моделей поведения пользователей и функций устройств — в этом инструменты MTD превосходно справляются.
Применительно к бизнес-сетям решения MTD могут отслеживать сетевой трафик на наличие подозрительной активности, такой как недействительные или поддельные сертификаты, чтобы остановить атаки посредника. Это позволяет им реагировать на угрозы в режиме реального времени, предоставляя информацию об уровне риска для всех устройств, подключенных к сети.
MTD и машинное обучение
Все инструменты MTD поддерживаются механизмом машинного обучения, который позволяет им распознавать шаблоны использования и помечать любые отклонения в поведении. Решения MTD также очень масштабируемы и могут одновременно контролировать десятки мобильных устройств Android. Когда одно из этих устройств начинает работать не так, как остальные, машинное обучение помогает инструменту MTD регистрировать аномалии и уведомлять ИТ-администраторов.
Внедрение решения MTD
Интеграция решения MTD в вашу стратегию безопасности мобильных устройств требует тщательной оценки различных критических факторов, включая отраслевые нормы и конфиденциальность данных, которые хранятся и/или передаются на ваших мобильных устройствах. В идеале ваше решение MTD должно быть частью более широкой стратегии безопасности, позволяющей блокировать вредоносный сетевой трафик и укреплять общую кибербезопасность бизнеса.
Разработка надежной защиты для мобильных устройств быстро становится важным компонентом стратегий кибербезопасности многих компаний. И хотя обнаружение угроз для мобильных устройств остается несовершенным средством обнаружения вредоносных программ, оно гораздо более эффективно, чем традиционные решения для защиты от вредоносных программ.
Другие преимущества использования инструментов MTD
Развертывание решения MTD дает ряд преимуществ, необходимых для современных удаленных или гибридных рабочих сред. Во-первых, это дает компании уверенность в реализации политики использования собственных устройств.Мало того, что решение MTD способно предотвращать кибератаки до того, как они станут серьезными проблемами, оно также дает ИТ-администраторам критическое представление об уровне риска мобильных сотрудников компании. Более того, развертывание решений MTD упрощает соблюдение нормативных требований, поскольку гарантирует безопасность конфиденциальных данных организации независимо от того, где они хранятся.
Таким компаниям, как ваша, нужны комплексные решения для защиты от кибератак, будь то компьютеры, ноутбуки или смартфоны. Чтобы получить экспертные рекомендации по ИТ-безопасности, позвоните нашим специалистам сегодня.
pstore block (pstore/blk) – это регистратор ошибок/паники, который записывает свои журналы на блочное и неблоковое устройство до того, как произойдет сбой системы. Вы можете получить эти файлы журнала, смонтировав файловую систему pstore, например:
концепции блоков pstore¶
pstore/blk обеспечивает эффективный метод настройки pstore/blk, который делит все конфигурации на две части: конфигурации для пользователя и конфигурации для драйвера.
Конфигурации пользователя определяют, как работает pstore/blk, например pmsg_size, kmsg_size и т. д. Все они поддерживают как Kconfig, так и параметры модуля, но параметры модуля имеют приоритет над Kconfig.
Конфигурации драйвера касаются блочного и неблочного устройства, например общего размера блочного устройства и операций чтения/записи.
Конфигурации для пользователя¶
Все эти конфигурации поддерживают как параметры Kconfig, так и параметры модуля, но параметры модуля имеют приоритет над Kconfig.
Вот пример параметров модуля:
Подробности каждой конфигурации могут вас заинтересовать.
blkdev¶
Используемое блочное устройство. В большинстве случаев это раздел блочного устройства. Это необходимо для pstore/blk. Он также используется для устройства MTD.
Когда pstore/blk собирается как модуль, «blkdev» принимает следующие варианты:
/dev/ представляет номер устройства диска
/dev/ представляет номер устройства раздела - номер устройства диска плюс номер раздела
/dev/ p — то же, что и выше; эта форма используется, когда имя диска с разделами заканчивается цифрой.
Когда pstore/blk встроен в ядро, «blkdev» принимает следующие варианты:
номер устройства в шестнадцатеричном представлении без ведущего 0x, например, b302.
PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF представляет собой уникальный идентификатор раздела, если он указан в таблице разделов. UUID может быть UUID EFI/GPT или относиться к разделу MSDOS в формате SSSSSSSS-PP, где SSSSSSSS — это шестнадцатеричное представление 32-битной «подписи диска NT», заполненное нулями, а PP — это нулевое заполненное шестнадцатеричное представление номера раздела, основанного на 1.
PARTUUID= /PARTNROFF= для выбора раздела по отношению к разделу с известным уникальным идентификатором.
: старший и младший номер устройства, разделенные двоеточием.
Он принимает следующие варианты для устройства MTD:
Имя устройства MTD. рекомендуется "pstore".
Номер устройства MTD.
kmsg_size¶
Размер фрагмента в КБ для пользовательского интерфейса oops/panic. Оно ДОЛЖНО быть кратно 4. Это необязательно, если вам не важен журнал oops/panic.
Существует несколько фрагментов интерфейса oops/panic в зависимости от оставшегося места, за исключением других интерфейсов pstore.
pstore/blk будет записывать фрагменты oops/panic один за другим и всегда перезаписывать самый старый фрагмент, если больше нет свободного фрагмента.
pmsg_size¶
Размер фрагмента в КБ для внешнего интерфейса pmsg. Оно ДОЛЖНО быть кратно 4. Это необязательно, если вам не важен журнал pmsg.
В отличие от внешнего интерфейса oops/panic, для внешнего интерфейса pmsg существует только один фрагмент.
Pmsg — это объект pstore, доступный в пользовательском пространстве. Записи в /dev/pmsg0 добавляются к чанку. После перезагрузки содержимое доступно в /sys/fs/pstore/pmsg-pstore-blk-0.
размер_консоли¶
Размер фрагмента в КБ для внешнего интерфейса консоли. Оно ДОЛЖНО быть кратно 4. Это необязательно, если вам не важен журнал консоли.
Как и в интерфейсе pmsg, для интерфейса консоли существует только один фрагмент.
Все журналы консоли будут добавлены к чанку. После перезагрузки содержимое доступно в /sys/fs/pstore/console-pstore-blk-0.
ftrace_size¶
Размер фрагмента в КБ для внешнего интерфейса ftrace. Оно ДОЛЖНО быть кратно 4. Это необязательно, если вам не важен журнал консоли.
Как и в интерфейсе oops, интерфейс ftrace состоит из нескольких фрагментов в зависимости от количества процессоров. Размер каждого фрагмента равен ftrace_size/processors_count.
Все журналы ftrace будут добавлены к чанку. При перезагрузке содержимое объединяется и становится доступным в /sys/fs/pstore/ftrace-pstore-blk-0.
Постоянная трассировка функций может быть полезна для отладки программных или аппаратных зависаний. Вот пример использования:
max_reason¶
Ограничением того, какие типы дампов kmsg сохраняются, можно управлять с помощью значения max_reason, как определено в перечислении kmsg_dump_reason include/linux/kmsg_dump.h. Например, чтобы хранить и ошибки, и панику, для параметра max_reason должно быть установлено значение 2 (KMSG_DUMP_OOPS), для хранения только сообщений паники значение max_reason должно быть равно 1 (KMSG_DUMP_PANIC). Установка этого параметра в 0 (KMSG_DUMP_UNDEF) означает, что фильтрация причин будет контролироваться загрузочным параметром printk.always_kmsg_dump: если он не установлен, это будет KMSG_DUMP_OOPS, иначе KMSG_DUMP_MAX.
Конфигурации драйвера¶
Драйвер устройства использует register_pstore_device со структурой pstore_device_info для регистрации в pstore/blk.
int register_pstore_device ( struct pstore_device_info *dev ) ¶
зарегистрировать неблокируемое устройство в pstore/blk
Параметры
структура pstore_device_info *dev
неблокировать информацию об устройстве
Вернуться
Другие - ошибка.
отменить регистрацию неблокирующего устройства в pstore/blk
Параметры
структура pstore_device_info *dev
неблокировать информацию об устройстве
Сжатие и заголовок¶
Блочное устройство достаточно большое для несжатых данных oops. На самом деле мы не рекомендуем сжатие данных, потому что pstore/blk вставит некоторую информацию в первую строку данных oops/panic. Например:
Это означает, что это OOPS|Panic в 16-й раз с момента первой загрузки. Иногда количество появлений oops|panic с момента первой загрузки важно для оценки стабильности системы.
Следующая строка вставляется файловой системой pstore. Например:
Это означает, что это OOPS во второй раз при последней загрузке.
Чтение данных¶
Данные дампа можно прочитать из файловой системы pstore. Формат этих файлов: dmesg-pstore-blk-[N] для интерфейса oops/panic, pmsg-pstore-blk-0 для интерфейса pmsg и так далее. Временная метка файла дампа записывает время срабатывания. Чтобы удалить сохраненную запись с блочного устройства, просто отсоедините соответствующий файл pstore.
Внимание в API чтения/записи паники¶
В случае паники ядро не будет работать намного дольше, задачи не будут запланированы, и большая часть ресурсов ядра не будет работать. Это похоже на однопоточную программу, работающую на одноядерном компьютере.
Следующие моменты требуют особого внимания при работе с API чтения/записи при панике:
Нельзя выделять память. Если вам нужна память, просто выделите ее во время инициализации драйвера блока, а не дожидаясь паники.
Должен быть опрошен, а НЕ управляем прерыванием. Расписания задач больше нет. Драйвер блока должен задержаться, чтобы гарантировать успешную запись, но НЕ переходить в спящий режим.
Нельзя взять любой замок. Нет ни другой задачи, ни общего ресурса; вы можете сломать все замки.
Просто используйте ЦП для передачи. Не используйте DMA для передачи, если вы не уверены, что DMA не сохранит блокировку.
Регистры управления напрямую. Пожалуйста, управляйте регистрами напрямую, а не используйте ресурсы ядра Linux. Сопоставьте ввод-вывод во время инициализации, а не ждите, пока не произойдет паника.
При необходимости перезагрузите блочное устройство и контроллер. Если вы не уверены в состоянии вашего блочного устройства и контроллера при возникновении паники, вы можете безопасно остановить и сбросить их.
pstore/blk поддерживает функцию psblk_blkdev_info(), определенную в linux/pstore_blk.h, для получения информации об использовании блочного устройства, такой как номер устройства, количество секторов и начальный сектор всего диск.
Внутреннее устройство блока pstore¶
Для разработчиков здесь приведены все важные структуры и API:
заголовок зоны для сброса в хранилище
Определение
Члены
подпись для указания заголовка (значение типа PSZ_SIG xor PSZONE)
длина данных в данных
смещение в данные, где начинается начало сохраненных байтов
Заголовок дампа kmsg для сброса в хранилище
Определение
Члены
магическое число для заголовка дампа kmsg
время срабатывания дампа kmsg
счетчик дампа kmsg
причина дампа kmsg (например, oops, паника и т. д.)
указатель на данные журнала
Описание
Это подзаголовок дампа kmsg после psz_buffer .
один сохраненный буфер
Определение
Члены
смещение зоны хранилища
имя внешнего интерфейса для этой зоны
тип внешнего интерфейса для этой зоны
указатель на буфер данных, управляемый этой зоной
указатель на старый буфер данных
байт в буфере->данные
должна ли эта зона восстанавливаться из хранилища
являются ли данные в буфере грязными
Описание
структура зоны в памяти.
все о рабочем состоянии pstore/zone
Определение
Члены
зоны хранения дампа kmsg
зона хранения pmsg
зона хранения консоли
зоны хранения ftrace
максимальное количество kpsz
счетчик общего количества прочитанных дампов kmsg
счетчик общего количества записей дампа kmsg
счетчик общего количества прочитанных pmsg зоны
счетчик общего количества прочитанных зон консоли
максимальное количество кадров в секунду
счетчик максимальной зоны чтения ftrace
счетчик дампов oops
счетчик панических дампов
не закончилось ли восстановление данных из хранилища
происходит ли паника
привязать к pstore_zone_info
информация из бэкенда
структура pstore
режим сброса для psz_zone_write()
Константы
не сбрасывать в хранилище, а обновлять данные в памяти
просто сбросить часть данных, включая метаданные, в хранилище
просто сбросьте метаданные зоны в хранилище
очистить всю зону
int psz_recovery ( struct psz_context *cxt ) ¶
восстановить данные из хранилища
Параметры
структура psz_context *cxt
контекст pstore/zone
Описание
восстановление означает чтение данных из хранилища после перезагрузки
Вернуться
0 в случае успеха, остальные в случае неудачи.
Структура внутреннего драйвера pstore/zone
Определение
Члены
Модуль, отвечающий за этот внутренний драйвер.
Имя внутреннего драйвера.
Общий размер в байтах, который может использовать pstore/zone. Оно должно быть больше 4096 и быть кратным 4096.
Размер зоны паники. Ноль означает отключено, в противном случае он должен быть кратен SECTOR_SIZE (512 байт).
Максимальная причина сохранения дампа kmsg.
Размер зоны pmsg совпадает с kmsg_size.
Размер зоны консоли, который совпадает с kmsg_size.
Размер зоны ftrace равен kmsg_size.
Общая операция чтения. Оба параметра функции, размер и смещение, относятся к объему хранилища. В случае успеха должно быть возвращено количество байтов, остальные означают ошибку.
То же, что и чтение, но со следующим номером ошибки: -EBUSY означает попытку записи позже. -ENOMSG означает попробовать следующую зону.
Общая операция стирания для устройства со специальным заданием удаления. Оба параметра функции, размер и смещение, относятся к объему хранилища. Возвращает 0 в случае успеха и другие значения в случае неудачи.
Операция записи используется только в случае паники. Это необязательно, если вас не волнует журнал паники. Параметры имеют относительное значение для хранилища. В случае успеха должно быть возвращено количество байтов, другие, за исключением -ENOMSG, означают ошибку. -ENOMSG означает попробовать следующую зону.
Читайте также: