OSDev http://osdev.su/ |
|
Осторожно! Баг в реализации APIC-а в VmWare Workstation 8 http://osdev.su/viewtopic.php?f=6&t=649 |
Страница 5 из 6 |
Автор: | Станислав [ 29 ноя 2012, 04:16 ] |
Заголовок сообщения: | Re: Осторожно! Баг в реализации APIC-а в VmWare Workstation |
Yoda писал(а): Я имел ввиду всего лишь простой образ вообще без файловой системы, но такой чтобы грузилось скомпилированное в файл ядро. Да, виртуалки легко делают пустой диск, а как ткда записать бинарник то? pavia писал(а): Тоже считаю что современные языки устарели. Но пока нет идей как сделать лучше. Сам по себе компилятор бесполезен, а если есть система, то программируя в ней на асме хочется некоторые моменты систематизировать. Например тот же стек (кстати узнал недавно, что процы АРМа его не требуют, а bl (аналог call) помещает адрес возврата не в стек, а в регистр LR, было бы интересно про них почитать, у них ещё говорят прерывания используют отдельные наборы регистров), в кривой IA-32 в стеке адреса вызовов, переменные, параметры, история сна, ... . При изучении АРМов вообще, всё что делалось для IA-32 кажется бредом, а особенно подход к загрузчикам(труд Yodы окажется бесполезным) система не должна зависеть от архитектуры так сильно. А на АРМах скоро все будем, IA-32 скоро умрёт(формально уже). Параметры компиляторы не позволяют смотреть прошлой функции, а я на асме могу спокойно через [esp+] смотреть параметры позапрошлой функции, про использование ebp для выделения параметров это вообще такой бред. Реч о том, что компилятор может спокойно отслеживать изменения в стеке и адресоваться на переменные в стеке прошлых функций. В трансляторе мне только не хватает голой инструкции для формирования таблицы релокации если org не известен, а то, что эти таблицы создаются для существующих форматов, это мне не нужно, как и сами форматы. В создании системы на данный момент считаю самым главным организовать работу с объектами имеющими стек, его переключение в системе и хранение там задач и всего остального, соответственно самое интересное. |
Автор: | Станислав [ 29 ноя 2012, 05:57 ] |
Заголовок сообщения: | Re: Осторожно! Баг в реализации APIC-а в VmWare Workstation |
Yoda писал(а): В твоей, может быть и есть. В моей пока что в непотребном виде. Да это всё надо писать, писать и писать, не отрывая рук от клавиатуры! Знакомо до боли, хотя больше переписываю, но изучать дольше. |
Автор: | pavia [ 29 ноя 2012, 07:41 ] |
Заголовок сообщения: | Re: Осторожно! Баг в реализации APIC-а в VmWare Workstation |
Цитата: Я имел ввиду всего лишь простой образ вообще без файловой системы, но такой чтобы грузилось скомпилированное в файл ядро. Для стартапа такой образ пойдёт, а уж дальше его развивать в ФС - это дело пользователя. При частых пересборках только одного ядра это очень удобно. Не интересно. У меня MBR читает BR. BR грузит из корня KLOADER.EXE (Формат MZ-EXE). BR у меня для FAT (FAT12,16,32). KLOADER.EXE грузит ядро с FAT. Да и ещё много всего грузит( настройки, ядро, драйвера, отладочную информацию, и тд.). Для отладки ядра надо что-то придумать. Если KLOADER я писал прямо на виртуалки и на ней компилировал и с неё запускал и отлаживал проблем не было. А вот ядро пока не могу собирать на виртуалке. Приходиться копировать на диск ручками. Утилиты в планах |
Автор: | phantom-84 [ 29 ноя 2012, 10:23 ] |
Заголовок сообщения: | Re: Осторожно! Баг в реализации APIC-а в VmWare Workstation |
Yoda писал(а): Я имел ввиду всего лишь простой образ вообще без файловой системы, но такой чтобы грузилось скомпилированное в файл ядро. Для стартапа такой образ пойдёт, а уж дальше его развивать в ФС - это дело пользователя. При частых пересборках только одного ядра это очень удобно. Ну Ё. Для этого есть cat или copy /b. На крайняк, если нужно подравнять конец образа, забиваете байтами под нужную границу. В Варе такое не нужно, а нужно просто правильно выставить тип соответствующей области вирт. диска и ее размер. Я об этом писал в самом начале: складываешь образ из "нулевой дорожки" и образа ядра, физически не объединяя файлы.
|
Автор: | phantom-84 [ 29 ноя 2012, 10:36 ] |
Заголовок сообщения: | Re: Осторожно! Баг в реализации APIC-а в VmWare Workstation |
pavia писал(а): А вот ядро пока не могу собирать на виртуалке. Приходиться копировать на диск ручками. Собирай образ сменного носителя для автоинсталляции обновленных файлов на образ харда и выключения (или, чтобы дважды не запускать эмуль, рестарта, если в процессе загрузки можно легко отказаться от повторной загрузки с этого сменного носителя в пользу харда, типа: "Press any key to boot from CD..." или в стартовом меню "Boot from first hard disk").
|
Автор: | Yoda [ 29 ноя 2012, 10:40 ] |
Заголовок сообщения: | Re: Осторожно! Баг в реализации APIC-а в VmWare Workstation |
Станислав писал(а): Да, виртуалки легко делают пустой диск, а как ткда записать бинарник то? Я для этих целей написал комплект утилит для бинарных манипуляций с файлами. Например, можно сколько-то байт начиная с определённой позиции из одного файла скопировать внутрь другого файла в другую позицию. В этом случае можно работать даже с неизвестной или новой ФС, - другими инструментами готовишь образ однократно, затем находишь внутри образа, где именно расположен файл ядра, а потом после каждой пересборки ядра бинарно его туда копируешь, внутрь образа. Я бы их приложил в архив тоже, но они не имеют прямого отношения к начальной загрузке ОС. Есть мысль взять их все и кинуть отдельным архивом. pavia писал(а): (труд Yodы окажется бесполезным) система не должна зависеть от архитектуры так сильно. В свете твоего пристрастия писать всё на АСМе и грядущей кончины x86/AMD64 (АМД, похоже, уже идёт с молотка), твой труд тоже будет бесполезен. pavia писал(а): Не интересно. У меня MBR читает BR. BR грузит из корня KLOADER.EXE А я и не говорю, что это офигенно интересная тема. Тем более, у тебя уже есть какие-то загрузчики. Но в качестве быстрого и удобного стартапа для начала ОСДева для тех, у кого ещё нет ничего, вполне сгодится. Да я и сам до сих пор им (с вариациями) пользуюсь. phantom-84 писал(а): Ну Ё. Для этого есть cat или copy /b. Неее, они не удобны. Ими нельзя что-то вбить внутрь файла. См. чуть выше. |
Автор: | phantom-84 [ 29 ноя 2012, 10:51 ] |
Заголовок сообщения: | Re: Осторожно! Баг в реализации APIC-а в VmWare Workstation |
Yoda писал(а): Неее, они не удобны. Ими нельзя что-то вбить внутрь файла. См. чуть выше. Что ты собрался вбивать внутрь файла в таком простом образе. Даже если формат "raw fs" предполагает хранение в бутсекторе (или еще где-либо) стартового номера сектора и размера загружаемого модуля, это можно сделать заранее в образе "нулевой дорожки" (пусть даже размер будет с запасом, если он может подрасти) или собирать "нулевую дорожку" на основе актуального размера модуля перед их объединением (или даже в процессе объединения).
|
Автор: | Yoda [ 29 ноя 2012, 11:22 ] |
Заголовок сообщения: | Re: Осторожно! Баг в реализации APIC-а в VmWare Workstation |
phantom-84 писал(а): Что ты собрался вбивать внутрь файла в таком простом образе. Ну, например, размер ядра. А в более сложном случае инжектировать ядро внутрь образа со сложной файловой системой. |
Автор: | Станислав [ 29 ноя 2012, 12:05 ] |
Заголовок сообщения: | Re: Осторожно! Баг в реализации APIC-а в VmWare Workstation |
Yoda писал(а): В свете твоего пристрастия писать всё на АСМе и грядущей кончины x86/AMD64 (АМД, похоже, уже идёт с молотка), твой труд тоже будет бесполезен. Ээ, чукча не дурак, чукча умный однако(как говорится). Я разрабатываю систему, и стараюсь не привязываться к архитектуре, а на АРМах она может даже и удачнее будет выглядеть (подозрение есть такое). А по поводу кончины x86, так тока на руку всем будет, архитектура АРМ более открытая, менее навязчивая, без хлама, даже свои модели процов можно будет у корейцев заказать (о чём мы все так мечтаем, но по карману бьёт(причём нереально, а для государства вполне) и не допустимо в интел). Если пойдут разговоры о АРМ, то глядиш и SII c grindars вернутся к обсуждениям, которые x86 обсуждать уже вообще смысла не видят, хотя знают в идеале. Yoda писал(а): Я для этих целей написал комплект утилит для бинарных манипуляций с файлами. Например, можно сколько-то байт начиная с определённой позиции из одного файла скопировать внутрь другого файла в другую позицию. В этом случае можно работать даже с неизвестной или новой ФС, - другими инструментами готовишь образ однократно, затем находишь внутри образа, где именно расположен файл ядра, а потом после каждой пересборки ядра бинарно его туда копируешь, внутрь образа. Я бы их приложил в архив тоже, но они не имеют прямого отношения к начальной загрузке ОС. Есть мысль взять их все и кинуть отдельным архивом. Так надо знать с какой позиции начинается первый сектор в файловом образе диска |
Автор: | phantom-84 [ 29 ноя 2012, 12:36 ] |
Заголовок сообщения: | Re: Осторожно! Баг в реализации APIC-а в VmWare Workstation |
Yoda писал(а): Ну, например, размер ядра. Про это я уже написал.Цитата: А в более сложном случае инжектировать ядро внутрь образа со сложной файловой системой. Это практически нереально. Где гарантия отсутствия фрагментации у исходного файла? Что если размер модуля изменяется (в большую или в меньшую сторону), т.е. как ты будешь вносить изменения в структуру ФС? Лучше уж тогда сразу делать полноценную утилиту добавления файлов в образ, чем при каждой записи задумываться о том, не нарушил ли ты структуру ФС.
|
Страница 5 из 6 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |