Board.KolibriOS.org

Понятно. Какая-то финская традиция

_________________
ушёл...

хороший вопрос пытливого человека! Поздравляю!

Ну наверное не совсем так. Вернее будет совсем не так если покумекать. Ну давай типа я тебе свое кумеканье изложу, думаю, будет полезно.
Смотри.
Разработчик, особенно ядра и всяких ядрёных и около ядрёных фенечек, может столкнуться, а вернее сказать, постоянно сталкивается
с проблемами в области "сердца системы". Следовательно нужно иметь инфу, чтобы разобраться, где да что. Дебаггер(ы), логи, дампы непременные спутники этого трудного пути разбирательств. Естественно, чем лучше и качественнее инфа, да еще если так сказать "на заказ" да внужном месте (в интересующем API стыке например) то эти сладости понятны. А вот если нет ничего? Если только, только возводится ядро или зона глюков приблизительна? Тогда хоть какой то программерский финт, уловка, ухищрение, могут сослужить незаменимую службу. А если он(а) этот финт оправдал несколько раз задумку автора, то, пожалуй она может остаться надолго и в ядре, скажем. Особенно если он(а) "карман не тянет", а работы впереди еще и края не намечается. И еще.
Автор, выкладывая исходники, пусть даже открытого проекта, может (ИМЕЕТ ПОЛНОЕ ПРАВО) НЕ ВЫКЛАДЫВАТЬ СВОИ ОТЛАДОЧНЫЕ технологии, модули, объекты, вспомогательные проги, среды... да что там говорить, комментарии!
Ведь это его мысли вслух! Порой, разгадка даже самому себе (через год-два) хода мысли дальше, зачем именно тут и так вот и так накодил тут именно, что хотел дочтичь, чего искал собственно(баг).....
Так вот, если это для него есть ценная инфа, а порой оно и бывает или это может подсказать конкурентам решение проблемы (ипр. и т.п.),
то....
комменты ЧИСТЯТСЯ,
т.е. удаляются либо совсем (возьми сорцы FASM полистай и подумай о стиле и табуляциях текста, например....) либо частично.
Сделать это сам понимаешь, как 2 байта.... обнулить.
Пишется прожка (парсер это слишком громко ), которая ищет символ ";" и удаляет весь остаток строки до 0Dh, 0Ah в листинге
любых сорцов типа asm в данном случае.
Как на автора бочку не гони, но он завсегда прав получается и перед законом и перед людьми, ибо он АВТОР. Это всегда НАДО иметь ввиду, полезно.
НУ теперь код смотрим

cross_order:
        ; load all registers in crossed order
        mov     eax, ebx
        mov     ebx, ecx
        mov     ecx, edx
        mov     edx, esi
        mov     esi, edi
        movzx   edi, byte[esp+28 + 4]
        call    dword [servetable+edi*4]
        ret

что видим? Ротацию видим. Что она дает кодеру если скажем мы имеем возможность мониторить(пусть просто смотреть вызовы) регистры
в некоторой точке памяти [servetable+edi*4]?
Кое что нужное да имеем! Можем с этого поиметь.
Ву вот залетаем мы сюда часто несанкционированно типа, циклимся непонятно откуда пусть и допустим именно на метку cross_order:
Тогда мониторинг покажет ротацию, сдвиг. Как это выглядит?
ПУсть был EAX = 0x66. Тогда логично, что в [servetable+edi*4] мы имеем EBX = 0x66 и это верно.
А если затем, сразу, "видим" еще вызов и еще и еще.... и уже ESI = 0x66......???
вот тебе простенькая типа фенечка. Глупо? Быть может и так, только, как именно думал автор и почему именно так, где то в 2003 году мы сейчас вряд ли узнаем...
Но уметь читать между строк всегда полезно, я так думаю.

Теперь немного понял Спасибо за такой развернутое объяснение)

_________________
ушёл...

Данное решение не сильно тормозит систему(регистровый сдвиг), однако занимает некоторое место. Было принято решение о прямом вызове сис. функций без регистрового сдвига. Сейчас осталось всего 4 сис. функции, которые используют это соглашение при вызове. Это 53, 58, 62, 63 сис.функции. Скоро система полностью избавиться от регистрового сдвига.

When Net branch will be merged in kernel, system function 53 will be deleted.

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein

Собственно, степень соответствия размышлений реальности видна уже по тому, что в реальности ротация идёт в другом направлении - новое значение eax берётся из старого значения ebx.

Угу. А заодно допустим, что при этом так грамотно рушится стек, что значение ESP оказывается таким же, каким было до "залетания", чтобы объяснить, почему следить за ESP недостаточно. Случайно всё так совпало, угу. И исключительно под этот случай подстраиваемся, бывает же. А ещё, разумеется, при этом мы совершенно игнорируем тот факт, что в первых версиях ядра всё было не так. Не было никакой метки cross_order, а случайное повторное попадание на метку i40 приводило не к повторной ротации регистров, а к повторной их загрузке в том же самом порядке.

В такой интерпретации - да.

Пишется, угу. Целая прожка, угу. Команда sed -i 's/;.*//' file.asm - и всё (короче даже, чем описание задания). Сэкономленное на "написании прожки" время можно использовать для флуда на форумах, домысливания целей других и, в особо исключительных случаях, для программирования ещё чего-нибудь. (Ну, если для красоты ещё потребовать, чтобы в случае, если кроме комментария на строчке только пробельные символы, то удалять всю строку, то команда несколько удлиннится до sed -i -e '/^\w*;/d' -e 's/;.*//' file.asm - опять же короче, чем формулировка. Для обхода всех файлов в подпапках можно засунуть команду в цикл for, если речь о виндовой командной строке, либо find, если об юниксовой.)


Моя версия такая. Сидит, значит, Ville, и... нет, не думу думает, а кодит. Надо как-то организовать связь между приложениями и ядром. Ясно, что удобнее всего передавать параметры в регистрах - не нужно думать думу о всяких структурах в памяти и перекодировкой указателей. Так, кодит Ville, какие бывают регистры? eax,ebx,ecx,edx,esi,edi, традиционно перечисляемые в таком порядке (esp выделенный, ebp не нужен). Значит, объявляет Ville, приложение пусть передаёт нужные параметры в этих регистрах, используя первые сколько надо в указанном порядке. А системные функции, продолжает Ville, пусть принимают нужные параметры в этих же регистрах. Естественно, номер системной функции ей самой передавать ни к чему. Следовательно, кодит Ville, в передатчике между приложениями и системными функциями регистры загружаются в порядке, смещённом относительно того, как они сохранены при системном вызове (да, там не было ротации регистров - желающие могут посмотреть на svn cat svn://kolibrios.org/trunk/core/syscall.inc@1). О том, что регистр ebx вообще-то традиционно non-volatile во всех конвенциях вызова, так что не мешало бы его трогать, только если не хватило eax+ecx+edx, мысли не возникает. О том, что вообще-то имеет смысл eax использовать под расходные материалы, а не под номер сисфункции, который можно и повторно использовать, - тоже. О том, что от такого решения может появиться совершенно ненужный код в будущем, при нормальном системном вызове, а не как он в данный момент закоден - тем более нет мысли, как и о нормальном системном вызове вообще.

Прошу реализовать API-функции ядра для работы с мьютексами. Или хотя бы функции блокировки/разблокировки именнованых областей памяти с привязкой к потоку

_________________
ушёл...

2 Serge
Нет я имел в виду функцию которая вызывалась бы из ring3 с помощью int 0x40

_________________
ушёл...

Nazarus
А для чего это нужно? Имеющимися средствами обойтись нельзя?

Asper
Да. Теперь уже не нужно Проблема решена и эта необходимость отпала.

_________________
ушёл...

Т.е. я хотел сказать, что "имеющимися средствами обойтись" МОЖНО. Хотя, ИМХО, ядро полноценной ОС должно предоставлять возможность работы с мьютексами прикладным программам.

_________________
ушёл...

В svn.1504 пофиксил баг, приводящий в определённых ситуациях к ошибке файловой системы 5 при чтении существующих папок (не совсем правильная обработка буквы ё в названиях соседних файлов/папок).

_________________
Ушёл к умным, знающим и культурным людям.

Меня наконец включили в KolibriOS team. Ура!

А что раньше забывали? О_о