Re: Обращение к разработчикам KolibriOS
Posted: Mon Oct 08, 2007 9:50 pm
Извини. Конечно, я видел этот пост. И собирался на него ответить, когда буду для этого готов. Я выложу CRT0 на fasm. Но CRT далеко не LIBC, а лишь малейшая её часть.diamond wrote:Похоже, меня проигнорировали...diamond wrote:Есть встречное предложение - использовать CRT на асме для программ Колибри (dosbox, скажем) (конечно, если оно в итоге заметно меньше, чем CRT на Си). Переработку menuetlibc при условии наличия большей части Си-библиотеки я могу обеспечить сам. Как было справедливо замечено, шансы на долгую память у кода и разработчика повышаются при использовании в двух ОСях.
И это тоже. И не только...diamond wrote: Это было завуалированное предложение написать эмулятор (или что-нибудь подобное) Колибри под Xameleon к разработчикам с этого форума?
А он нужен, эмулятор под Linux? Для графики у Linux есть XWindow и SDL. Также под Linux имеется десяток различных эмуляторов, в том числи и Wine.diamond wrote: На данный момент нет даже эмулятора под Linux, а Linux - очень известная система, у которой в том числе и на этом форуме есть сторонники! (Кстати, там для эмуляции Колибри даже ядро модифицировать не надо.)
В общем, на данном этапе я предлагаю ознакомить всех разработчиков KoibriOS с идеологией микроядра L4. Обрати внимание, я не говорю о Хамелеоне, а говорю о L4. Потратив несколько дней на изучение KolibriOS и чтение форума, я обнаружил, что у Kolibri имеются некоторые проблемы, решение которых предполагает перепроектирование системы. Навскидку - поддержка многопроцессорности, остановка подсистемы ввода/выводы во время операций с большими файлами.
Т.е. со временем всё равно придётся перепроектировать. Надеюсь, это никто не оспаривает?
Так вот, знакомство с концепцией L4 позволит разработчикам Kolibri узнать один из способов (далеко не самый худший) решения этих проблем.
В поддержку своих слов процитирую кусок кода из Kolibri (kernel/core/sync.inc):
Этот код будет идеально работать на однопроцессорной машине, но даже на Pentium4 с технологией HT он с большой вероятностью приведёт к ошибке, которую при этом будет трудно отловить.macro WaitSimpleMutex name
{
local start_wait,ok
start_wait=$
cli
cmp [name],dword 0
jz ok
sti
call change_task
jmp start_wait
ok=$
push eax
mov eax,dword [TASK_BASE+second_base_address]
mov eax,[eax+TASKDATA.pid]
mov [name],eax
pop eax
sti
}
Почему? Потому что cli запрещает прерывания, соответственно, переключения задач не произойдёт. Но при этом второй процессор продолжает работать и может обратиться к этому же самому ресурсу.