Смотря что понимать под "смотрел" :) Само существование JSLinux меня и сподвигло сделать "такое же, но с JIT". В первой части как раз был небольшой обзор существовавших ранее эмуляторов и известных мне попыток портировать QEMU.
Детально в JSLinux я не углублялся. Насколько я помню, там была задумка, наоборот, используя все возможности JS реализовать эффективный эмулятор практически с нуля. Я же не хотел разбираться со всеми деталями x86 (не говоря уже о десятке других архитектур), а сосредоточиться на JIT.
А еще можно не бояться стирать ключ в машинке — разработчики говорят, что он это выдерживает без проблем.
Мельком увидел фразу в контексте аппаратных ключей. Воображение начало рисовать управляющую плату, которая делает некий "правильный" erase криптографического ключа — а то здесь же даже кнопку не разместишь.
Перечитал. Понял, что и "стирать" здесь — wash, а не erase, и ключ — это физическая плата, а не данные в ней, и машинка несколько другая.
Сам использовал asciinema для иллюстрации процесса загрузки свеженастроенной платы. Может, конечно, и баловство, но по идее окно minicom с реально то бегущим, то не бегущим текстом — это намного больший эффект погружения.
Кроме того, не уверен, корректно ли это отрабатывает конкретно asciinema, но нужно помнить, что вывод консольной утилиты — "это не только 10 кб текста, но и не очень легко усвояемые escape-последовательности". Бывают обычные "консольные" утилиты (да хоть тот же git), для наглядности переписывающие какой-нибудь индикатор прогресса. Бывают полноценные tui (тот же aptitude), "скриншот" которых, может, и получится передать в виде текста в <pre>, но не весь процесс работы.
Проскакивала когда-то статья: Отключённый промышленный твердотельник может потерять данные за неделю. В ней было некое количество контринтуитивных, но, вроде, логичных, утверждений: например, ситуация "хранить диск придётся при повышенной температуре — так хоть при записи пожалею, охлажу" на самом деле самая неблагоприятная. Так что стёбом здесь выглядит разве что термин "заряжать флешку". Хотя выше уже закономерно интересуются, будет ли это всё отрабатывать, если подать только питание.
Кстати, можно щёлкнуть по бейджику — должен появиться список репозиториев (возможно, с пометкой "and more"). Если ваш ник на GitHub такой же, как на Хабре, то в вашем случае как раз был contribution в чужой проект, попавший в архив.
Есть такая забавная библиотека GNU Pth. У неё примерно такой же API, как у Pthreads, но вместо полноценных потоков она использует корутины и щепотку костылей. Возможно, получится предсказуемее и более "fork-friendly".
А, и ещё: у MemTest есть немало параметров командной строки, в частности, один из них позволяет задать список тестов, поскольку сделать это при включённом btrace вы вряд ли сможете. Ссылку вновь даю на свой форк, просто потому, что не знаю, где выложена референсная версия в распакованном виде.
Оказывается, btrace постоянно требует нажать клавишу, чтобы продолжить, я же был уверен, что у меня ввод по serial-порту принципиально не работал — оказывается, он у меня "принципиально работал", причём независимо от того, есть ли реальный ввод… В общем, btrace может быть не совсем удобен для отладки "отдалённой" ошибки.
А оригинальный MemTest у меня вообще не собрался — жалуется на тучу отсутствующих символов. По поводу зависаний — я попробовал запустить в QEMU, и он тоже иногда подвисает изрядно (а иногда — намертво).
Зато я понял, что не компилирующийся с аналогичными ошибками мой порт с ARCH=i386 — это не я сломал, а "оно само". Более того, в итоге у меня есть буквально штук пять дебиановских патчей, один из которых всё чинит, и нужно просто понять, как. Так что спасибо за вопрос! :)
На счёт изначальной просьбы: честно скажу, перспектива "удалённой" отладки SMP-кода с соответствующим чтением хитрых спецификаций на x86 меня несколько пугает. :) У меня у самого, как ни решу проверить память, SMP-режим вечно вис, и я его не использовал. Я бы вам посоветовал во-первых, убедиться, что поведение обеих версий воспроизводимо (в том смысле, что различия в поведении — это не просто "шум"). Во-вторых, было бы логично как-нибудь запихнуть в параметры запуска MemTest опцию "btrace". У меня в GRUB 2 это выглядит как "linux16 /boot/memtest86+.bin btrace", а потом "boot".
Уточните, пожалуйста, откуда взят оригинал: с memtest.org, из дистрибутива или откуда-то ещё. Просто логично было бы накладывать этот патч именно поверх имеющихся в работающей версии.
Более того, у U-Boot, вроде бы, тоже имеется встроенная команда вроде memtest или что-то такое (прямо в загрузчике). Но попробовать всё-таки было интересно. Ну и MemTest, по слухам, и правда "умный", хотя видел упоминания из серии "MemTest нагружает память не так сильно, как хотелось бы (ссылка на статью с более продвинутым алгоритмом), но вот test номер N очень близок" (кстати, возможно именно этот тест был полностью на ассемблере, и я его пока так же полностью и закомментировал). Впрочем, MemTest можно было бы использовать как удобную стандартную оболочку для запуска "вот этого всего" из теоретических статей.
Вроде, она и есть. Могу посмотреть в списке заказов точную ссылку, но, если ничего не напутал в первой статье, то ссылка такая: https://ru.aliexpress.com/item/1892377255.html(надеюсь, это не считается рекламой)
Кстати, пока ковырялся в коде, наткнулся на такие строчки (ссылку даю на свой "форк", потому что сам исходники качал с официального сайта вообще в архиве):
/* Now setup the test parameters based on the current test number */
if (v->pass == 0) {
/* Reduce iterations for first pass */
c_iter = tseq[test].iter/FIRST_DIVISER;
} else {
c_iter = tseq[test].iter;
}
«Продвинутые пользователи мемтеста» об этом, наверное, и так прекрасно знали, а вот я лишь догадывался (что-то он как-то быстро, а потом как-то не очень).
Я подозреваю, что даже для JJTree можно такие сериализаторы генерировать как-нибудь, если допилить генератор парсеров. Хотя, в общем случае — не факт, не удивлюсь, если про это даже какая-нибудь теорема есть. :)
Здесь же идея была в том, чтобы взять готовые модули (в особенности, свеженаписанный модуль для Modelica) и разом получить инструмент для всех этих языков (даже для неопубликованных реализаций). В целом, две существующих стратегии запросто обобщаются на произвольное описание ANTLR / JJTree / чего-угодно — хоть Kaitai Struct. Хотя результат, да, может получиться менее удачный, чем если использовать "конструктивный" подход.
Смотря что понимать под "смотрел" :) Само существование JSLinux меня и сподвигло сделать "такое же, но с JIT". В первой части как раз был небольшой обзор существовавших ранее эмуляторов и известных мне попыток портировать QEMU.
Детально в JSLinux я не углублялся. Насколько я помню, там была задумка, наоборот, используя все возможности JS реализовать эффективный эмулятор практически с нуля. Я же не хотел разбираться со всеми деталями x86 (не говоря уже о десятке других архитектур), а сосредоточиться на JIT.
Мельком увидел фразу в контексте аппаратных ключей. Воображение начало рисовать управляющую плату, которая делает некий "правильный" erase криптографического ключа — а то здесь же даже кнопку не разместишь.
Перечитал. Понял, что и "стирать" здесь — wash, а не erase, и ключ — это физическая плата, а не данные в ней, и машинка несколько другая.
Недавно узнал про systemd-boot. Был удивлён.
Сам использовал asciinema для иллюстрации процесса загрузки свеженастроенной платы. Может, конечно, и баловство, но по идее окно minicom с реально то бегущим, то не бегущим текстом — это намного больший эффект погружения.
Кроме того, не уверен, корректно ли это отрабатывает конкретно asciinema, но нужно помнить, что вывод консольной утилиты — "это не только 10 кб текста, но и не очень легко усвояемые escape-последовательности". Бывают обычные "консольные" утилиты (да хоть тот же git), для наглядности переписывающие какой-нибудь индикатор прогресса. Бывают полноценные tui (тот же aptitude), "скриншот" которых, может, и получится передать в виде текста в
<pre>, но не весь процесс работы.Проскакивала когда-то статья: Отключённый промышленный твердотельник может потерять данные за неделю. В ней было некое количество контринтуитивных, но, вроде, логичных, утверждений: например, ситуация "хранить диск придётся при повышенной температуре — так хоть при записи пожалею, охлажу" на самом деле самая неблагоприятная. Так что стёбом здесь выглядит разве что термин "заряжать флешку". Хотя выше уже закономерно интересуются, будет ли это всё отрабатывать, если подать только питание.
Кстати, можно щёлкнуть по бейджику — должен появиться список репозиториев (возможно, с пометкой "and more"). Если ваш ник на GitHub такой же, как на Хабре, то в вашем случае как раз был contribution в чужой проект, попавший в архив.
Критерии указаны в https://archiveprogram.github.com в разделе "What’s in the 02/02/2020 snapshot".
Если что, статья в итоге была опубликована, хотя и без тестирования на Windows.
Есть такая забавная библиотека GNU Pth. У неё примерно такой же API, как у Pthreads, но вместо полноценных потоков она использует корутины
и щепотку костылей. Возможно, получится предсказуемее и более "fork-friendly".А, и ещё: у MemTest есть немало параметров командной строки, в частности, один из них позволяет задать список тестов, поскольку сделать это при включённом
btraceвы вряд ли сможете. Ссылку вновь даю на свой форк, просто потому, что не знаю, где выложена референсная версия в распакованном виде.Оказывается,
btraceпостоянно требует нажать клавишу, чтобы продолжить, я же был уверен, что у меня ввод по serial-порту принципиально не работал — оказывается, он у меня "принципиально работал", причём независимо от того, есть ли реальный ввод… В общем,btraceможет быть не совсем удобен для отладки "отдалённой" ошибки.А оригинальный MemTest у меня вообще не собрался — жалуется на тучу отсутствующих символов. По поводу зависаний — я попробовал запустить в QEMU, и он тоже иногда подвисает изрядно (а иногда — намертво).
Зато я понял, что не компилирующийся с аналогичными ошибками мой порт с
ARCH=i386— это не я сломал, а "оно само". Более того, в итоге у меня есть буквально штук пять дебиановских патчей, один из которых всё чинит, и нужно просто понять, как. Так что спасибо за вопрос! :)На счёт изначальной просьбы: честно скажу, перспектива "удалённой" отладки SMP-кода с соответствующим чтением хитрых спецификаций на x86 меня несколько пугает. :) У меня у самого, как ни решу проверить память, SMP-режим вечно вис, и я его не использовал. Я бы вам посоветовал во-первых, убедиться, что поведение обеих версий воспроизводимо (в том смысле, что различия в поведении — это не просто "шум"). Во-вторых, было бы логично как-нибудь запихнуть в параметры запуска MemTest опцию "btrace". У меня в GRUB 2 это выглядит как "linux16 /boot/memtest86+.bin btrace", а потом "boot".
Уточните, пожалуйста, откуда взят оригинал: с memtest.org, из дистрибутива или откуда-то ещё. Просто логично было бы накладывать этот патч именно поверх имеющихся в работающей версии.
Собрать-то собрал: https://gist.github.com/atrosinenko/f61a4865f35e4702ae3a1f8a49aee71e
Вот с проверкой работоспособности — сложнее. Если что, собирал вот так:
То есть, этот MemTest включает в себя патчи из текущей Ubuntu.
Более того, у U-Boot, вроде бы, тоже имеется встроенная команда вроде
memtestили что-то такое (прямо в загрузчике). Но попробовать всё-таки было интересно. Ну и MemTest, по слухам, и правда "умный", хотя видел упоминания из серии "MemTest нагружает память не так сильно, как хотелось бы (ссылка на статью с более продвинутым алгоритмом), но вот test номер N очень близок" (кстати, возможно именно этот тест был полностью на ассемблере, и я его пока так же полностью и закомментировал). Впрочем, MemTest можно было бы использовать как удобную стандартную оболочку для запуска "вот этого всего" из теоретических статей.Вроде, она и есть. Могу посмотреть в списке заказов точную ссылку, но, если ничего не напутал в первой статье, то ссылка такая: https://ru.aliexpress.com/item/1892377255.html (надеюсь, это не считается рекламой)
Кстати, пока ковырялся в коде, наткнулся на такие строчки (ссылку даю на свой "форк", потому что сам исходники качал с официального сайта вообще в архиве):
«Продвинутые пользователи мемтеста» об этом, наверное, и так прекрасно знали, а вот я лишь догадывался (что-то он как-то быстро, а потом как-то не очень).
Собственно, у меня тоже была отчасти похожая ситуация. Что-то вроде «в каждом четырёхбайтном (или восьмибайтном?) слове обнулилось по маске 0x0000ff00». Хотя, конечно, и близко не столь коварная, как в приведённой истории.
Интересный эффект:
Это парсер глючит или я чего-то недопонял?
Я подозреваю, что даже для JJTree можно такие сериализаторы генерировать как-нибудь, если допилить генератор парсеров. Хотя, в общем случае — не факт, не удивлюсь, если про это даже какая-нибудь теорема есть. :)
Здесь же идея была в том, чтобы взять готовые модули (в особенности, свеженаписанный модуль для Modelica) и разом получить инструмент для всех этих языков (даже для неопубликованных реализаций). В целом, две существующих стратегии запросто обобщаются на произвольное описание ANTLR / JJTree / чего-угодно — хоть Kaitai Struct. Хотя результат, да, может получиться менее удачный, чем если использовать "конструктивный" подход.