Рефакторинг ядра

[Vaicheslav97]

Приведите более сложный пример такой адресации желательно из ядра пожалуйста как мне кажется это будет более понятно стоит такое добавлять или нет.

[art_zh]

Приведите более сложный пример такой адресации желательно из ядра пожалуйста как мне кажется это будет более понятно стоит такое добавлять или нет.

ну вот навскидку kernel.asm: syscall_getarea (со строчки 4580 и ниже)
если привести команды типа lea ebp, [ebp*3] к "удобочитаемому" виду,
тогда вообще никто не сможет разобраться что там за фигня наворочена и зачем

[art_zh]

или посмотри programs/other/fft/fht4code.asm
как можно реализовать сложный математический алгоритм,
работающий с плотнейшими таблицами данных,
не теряя удобочитаемости и только в стандартных ассемблерных инструкциях

[turbocat]

Я всё понял уже после первого кометария. Нет так нет. Это было мое видение. А наезжать ненадо. Я буду сам для себя решать чем мне заниматься, а чем нет.

[Doczom]

Некоторые мысли о файловой подсистеме: Сейчас работа с файлами происходит через 70 сисфункцию, которая не сказать чтобы была удобной в использовании(про скорость вообще говорить не стоит). Кроме этого данная сисфункция совсем не совместима с аналогами из других систем. Использование файловых дескрипторов для работы с файлами и стандартных функций read write упростило бы портирование софта, увеличило скорость работы(не нужно было бы каждый раз полное имя файла и диск искать), упростило бы интерфейс для работы с файлами. Сейчас модель драйверов файловых систем вполне позволяет это сделать, но есть один такой интересный драйвер, а именно iso9660 который работает через какие-то "костыли" и у которого апи заметно отличается от остальных фс.
Для переписывания файловой подсистемы на использование файловых дескрипторов придётся переписать всё работу с CD дисками, основная система работы с файлами скорее всего останется без изменений.

Вопросы к знающим людям:
Взаимодействуют ли драйвера файловых систем с именем файла, передаваемым в структуре файла или же используется только полное имя передаваемое в кодировке UTF-8 ?

[sober_dev]

а именно iso9660 который работает через какие-то "костыли" и у которого апи заметно отличается от остальных фс

Костыли написал я. Код был написан тогда, когда код всей дисковой подсистемы выглядел и функционировал совершенно иначе. При внедрении поддержки USB добавили еще костылей. Однако, за столько лет не нашлось людей готовых переработать код. Так что пожелаю удачи!

Взаимодействуют ли драйвера файловых систем с именем файла, передаваемым в структуре файла или же используется только полное имя передаваемое в кодировке UTF-8 ?

Все зависит от файловой системы и какая кодировка в ней базовая. Например, для iso9660 могут присутствовать структуры для нескольких кодировок одновременно. Текущий драйвер ищет UTF-16.

[Doczom]

Спасибо за ответ

[sober_dev]

Шуточная ссылка в тему https://pikabu.ru/story/chuzhoy_kod_5762938

[sober_dev]

Doczom
Да, еще вспомнил. ATA и ATAPI команды "чуть-чуть" отличаются, если будешь ковырять код, то вспомнишь мои слова.
И еще код работает в PIO режиме, а не DMA как IDE ATA и SATA жесткие диски. Реализовать пакетный режим DMA для ATAPI я тогда не осилил. Так что опять же могу только пожелать удачи.
З.Ы. И еще размер сектора в 2048 байт, а отличие от жестких дисков, где исторически было 512 байт, а потом появились диски с размером сектора в 4096 байт.

[Doczom]

Наличие в api ядра сисфункций для вывода звука(20 и 55 сисфункции) немного выбивается из общей системы, что вызывает путаницу как с проверкой работоспособности звука так и в разработке новых приложений. Логичным шагом по решению этой проблемы было бы добавления функционала 55 сисфункции в драйвер sound при отсутствии других устройств вывода или при ручном выборе данного режима и переписывания всех программ на использование драйвера sound. Это позволит стандартизировать работу со звуком и кроме этого немного уменьшить размер ядра, удалив устаревший код.
Кроме этого в репозитории есть как минимум 3 программы использующий уже уж удалённые подфункции 55 сисфункции и 58 сисфункцию для работы с файлами, есть так же программы примеры работы с портами и их прерываниями из юзерспейса, но не думаю что это нужно чинить, тут придётся драйвер писать .

[Vaicheslav97]

Функция 9
; +6: word: number of the thread slot, which window has in the window stack
; position ecx (has no relation to the specific thread)

короче параметр есх используется в двух целях как 1)номер интересующего потока 2)номер позиции оконого стека для получения номера потока
Как мне кажется по хорошему такой функционал нужно выделять отдельной функцией.

И также думаю стоит добавить потокам дополнительный идентификатор а то хрен поймёшь дополнительный или основной поток, или чем он вообще занимается.
Это позволит определить что за поток крашнулся первым(основной или дополнительный если дополнительный то какого было его предназначение) и возможно реализовать переключение в дебагере между потоками или это куда сложнее?

Хоть с точки зрения системы потоки равносильны, но с точки зрения приложения обычно у нас есть основной поток/окно и дополнительные потоки/окна что существуют чтобы отображать контекстные меню и тому подобное.
Также потоки могут использоваться для декодирования видео и результат передаётся в основное видимое окно. И уж лучше знать где произошел вылет на стороне основного окна или на стороне декодера что в дополнительном потоке?