OSDev

Тестируется ОС, да и вообще практически любое системное ПО. Не видел еще ни одного товарища который тестит разрабатываемый драйвер или модуль ядра на том же самом компе, на котором его и кодирует. А с прикладным ПО, согласен, все намного проще. С его помощью обычно не получается пилить сук на котором сидишь :)

Да ладно есть масса драйверов, которые можно и нужно тестировать непосредственно на целевой платформе. Речь идет не о стабильности их работы, а о правильном управлении устройствами с их стороны. От того что звук выводится с хрипотцой или принтер печатает не то, что должен, оси пока не падают. У меня часть драйверов запускается непосредственно менеджером задач. Они при необходимости могут быть перезапущены без перезагрузки. До печати и звука я еще не дошел, но вот драйверы файловых систем таким способом тестирую постоянно: монтирую ФС на тестовом носителе, выполняю на нем операции с файловой системой, демонтирую и прогоняю тест на целостность файловой системы или просто сравниваю с заранее подготовленным шаблоном результата. Кроме того, всю логику работы драйвера на время или навсегда можно вынести в юзермод, оставив в кернелмоде только выполнение привилегированных команд по взаимодействию с устройством. Тогда даже нестабильные драйверы можно будет перезапускать.

Делает. Я с кривостями эмуляции ЦПУ не сталкивался. Кривости BIOS и периферии не так далеко заходят, чтобы сказать - "это нерабочая машина". В любом случае в РЕАЛЬНОМ железе встречаются куда большие кривости. Таким образом, могу констатировать, что если есть девайс (в данном случае виртуальный), который ближе к реальному железу, чем некоторые реальные представители, и если на этом девайсе нормально работает ВСЁ существующее системное ПО, то этот (виртуальный) девайс вполне годится для разработки нового системного ПО.

Здесь мы сталкиваемся с общепринятой парадигмой "кто виноват". Подавляющее большинство разработчиков принимает т.н. "ленивый" подход. Т.е. если его программа работает на 9 машинах из 10, то они просто декларируют, что десятая машина кривая и что пользователь сам виноват, что приобрёл такое гуано. Я же предпочитаю заставить ПО работать в 10 случаях из 10. А применительно к конкретной ситуации не утверждать, что Бокс кривой и непригоден для серьёзной работы, а преспокойно работать с ним, не испытывая ни малейших затруднений. При этом не забывая периодически проверять работу на другом железе. Кстати, пока ещё ни разу не было, чтобы результат разработки в Боксе не заработал на реальном компе. Вру. Было. Из-за кривизны БИОСа одного из реальных компов :)


Вот именно! Два клика - и готово! Так и есть - один клик на сборку проекта, второй - на запуск. Как можно после этого утверждать об отсутствии пользы?


Вот об этом я и говорю. Влезая в экстраординарные конструкции не стоит сразу винить в Бокс в проф-непригодности. Лучше отказаться от экстраординарности в пользу надёжности, переносимости и совместимости по железу.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Так я так и делаю. Но это вовсе не означает, что при этом нельзя поругать бокс за то, что в нем не реализована фишка, на которую изначально ориентировалась твоя программа. Кстати, некоторые решения, продиктованные боксом, оказались более простыми и эффективными, так что его "недоделанность" делает наши программы не только более универсальными, но иногда еще и более эффективными. А ситуация с far jump'ом мне запомнилась потому, что по сути она была обратная. Т.е. поведение бокса скрывало реальное поведение процессора. Ситуация не прояснилась до сих пор, хотя 32-разрядная инструкция в любом случае нивелирует все возможные негативные последствия. Но теперь мне просто интересно в этом разобраться (есть вероятность, что в новой документации написано полное... - кто ж откажется от возможности постебаться над Intel :) ).

Нет. Использую его для проверки более высокоуровневого функционала с применением самодиагностики.
Если нужно ковыряться в железе, то беру Bochs. Там обычно достаточно заглянуть в журнал выполнения bochsout.txt чтобы найти причину сбоя, без всякой отладки.

Один раз случился подвох с Bochs, потому что у него физическая память изначально обнулена, а на реальном железе содержит мусор. Поэтому было трудно выявить неочищенные структуры в системе.

Пишу свой эмулятор. Да уж если раньше я более или менее нормально относился к x86, то теперь понимаю, какой это отстой. Сделал половину команд х286. Думал к концу недели закончить с командами. Есть идеи на чём проверить?
И к концу года сделать достаточную эмуляцию периферийного железа.
Железо будет классическое - PIIX4 мой домашний тестовый компьютер.

А если пробовать ещё эмулировать поведение разных процессоров... Ведь они не полностью совместимы даже снизу вверх, причём не все отличия описаны в документации. Про недокументированные функции вообще молчу...

pavia, есть тесты специально для эмуляторов.

Для начала на DOS-е. Он хорош тем, что работает исключительно на функционале BIOS, так что эмуляции железа не требуется вообще.
Как всё отладишь, то пробуй запустить GRUB - это ворота во все современные ОС.

Можно подробнее? А то я поискал не нашёл.


А информация 100% ?

Одна из причин зачем решил делать эмулятор это то что мне не понравилась как устроен режим vm86 в IA32 видимо его поэтому и выкинули из x64. Уж больно они его криво присобачили. Хочу эмулировать прерывания биоса с прямым доступом к железу. То есть вызывать прерывания биоса из защищенного режима.