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

Internal structure and you change requests/suggestions
  • Vaicheslav97 wrote:Приведите более сложный пример такой адресации желательно из ядра пожалуйста как мне кажется это будет более понятно стоит такое добавлять или нет.
    ну вот навскидку kernel.asm: syscall_getarea (со строчки 4580 и ниже)
    если привести команды типа lea ebp, [ebp*3] к "удобочитаемому" виду,
    тогда вообще никто не сможет разобраться что там за фигня наворочена и зачем
  • или посмотри programs/other/fft/fht4code.asm
    как можно реализовать сложный математический алгоритм,
    работающий с плотнейшими таблицами данных,
    не теряя удобочитаемости и только в стандартных ассемблерных инструкциях
  • Я всё понял уже после первого кометария. Нет так нет. Это было мое видение. А наезжать ненадо. Я буду сам для себя решать чем мне заниматься, а чем нет.
    Изобретайте колёса каждый раз, когда хотите написать новую программу.
  • Некоторые мысли о файловой подсистеме: Сейчас работа с файлами происходит через 70 сисфункцию, которая не сказать чтобы была удобной в использовании(про скорость вообще говорить не стоит). Кроме этого данная сисфункция совсем не совместима с аналогами из других систем. Использование файловых дескрипторов для работы с файлами и стандартных функций read write упростило бы портирование софта, увеличило скорость работы(не нужно было бы каждый раз полное имя файла и диск искать), упростило бы интерфейс для работы с файлами. Сейчас модель драйверов файловых систем вполне позволяет это сделать, но есть один такой интересный драйвер, а именно iso9660 который работает через какие-то "костыли" и у которого апи заметно отличается от остальных фс.
    Для переписывания файловой подсистемы на использование файловых дескрипторов придётся переписать всё работу с CD дисками, основная система работы с файлами скорее всего останется без изменений.

    Вопросы к знающим людям:
    Взаимодействуют ли драйвера файловых систем с именем файла, передаваемым в структуре файла или же используется только полное имя передаваемое в кодировке UTF-8 ?
  • а именно iso9660 который работает через какие-то "костыли" и у которого апи заметно отличается от остальных фс
    Костыли написал я. Код был написан тогда, когда код всей дисковой подсистемы выглядел и функционировал совершенно иначе. При внедрении поддержки USB добавили еще костылей. Однако, за столько лет не нашлось людей готовых переработать код. Так что пожелаю удачи!
    Взаимодействуют ли драйвера файловых систем с именем файла, передаваемым в структуре файла или же используется только полное имя передаваемое в кодировке UTF-8 ?
    Все зависит от файловой системы и какая кодировка в ней базовая. Например, для iso9660 могут присутствовать структуры для нескольких кодировок одновременно. Текущий драйвер ищет UTF-16.
    Last edited by sober_dev on Sat Mar 05, 2022 12:54 am, edited 2 times in total.
  • Спасибо за ответ
  • Шуточная ссылка в тему https://pikabu.ru/story/chuzhoy_kod_5762938
  • Doczom
    Да, еще вспомнил. ATA и ATAPI команды "чуть-чуть" отличаются, если будешь ковырять код, то вспомнишь мои слова.
    И еще код работает в PIO режиме, а не DMA как IDE ATA и SATA жесткие диски. Реализовать пакетный режим DMA для ATAPI я тогда не осилил. Так что опять же могу только пожелать удачи.
    З.Ы. И еще размер сектора в 2048 байт, а отличие от жестких дисков, где исторически было 512 байт, а потом появились диски с размером сектора в 4096 байт.
  • Наличие в api ядра сисфункций для вывода звука(20 и 55 сисфункции) немного выбивается из общей системы, что вызывает путаницу как с проверкой работоспособности звука так и в разработке новых приложений. Логичным шагом по решению этой проблемы было бы добавления функционала 55 сисфункции в драйвер sound при отсутствии других устройств вывода или при ручном выборе данного режима и переписывания всех программ на использование драйвера sound. Это позволит стандартизировать работу со звуком и кроме этого немного уменьшить размер ядра, удалив устаревший код.
    Кроме этого в репозитории есть как минимум 3 программы использующий уже уж удалённые подфункции 55 сисфункции и 58 сисфункцию для работы с файлами, есть так же программы примеры работы с портами и их прерываниями из юзерспейса, но не думаю что это нужно чинить, тут придётся драйвер писать .
  • Функция 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)номер позиции оконого стека для получения номера потока
    Как мне кажется по хорошему такой функционал нужно выделять отдельной функцией.

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

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

    Сейчас эта проблема можно сказать не актуальна, так как ide atapi дисководы работают в обход основной дисковой системы, но при написании драйвера для монтирования образов и переписывании драйвера на iso9660 эта проблема очень актуальна.
    Кроме этого, для atapi дисков не хватает нескольких функций, например получения lba последней сессии записи, из за чего поддержка мультисессии в iso9660 и UDF может отсутствовать.

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


    2) Внедрения функций чтения/записи дисковых устройств:
    Для внедрения чтения/записи секторов диска/раздела для раздела должно существовать поле, блокирующее работу с разделом для драйверов фс, и других программ.

    3) Использование состояния потока в обработке работы оконной подсистемы:
    Сейчас для перерисовки окна используется состояние потока, что добавляет неудобства в код(надо WDATA в APPTADA конвертить) и лишнюю привязку окон к потоку, что не очень то и хорошо. Как вариант решения, которое уже частично используется: расширение WDATA и перенос всех связанных с окнами полей из APPDATA в WDATA. Сейчас структура WDATA имеет размер 64 байта и её расширению препятствует только нахождение на статичном адресе буфера для cd дисков.

    4) Отсутствие подсистемы устройств:
    Её нет, совсем. Нужна хоть какая-то подсистема для хранения данных о всех устройствах, чтобы можно было посмотреть туда и увидеть что есть такой-то com-порт например и знать что у него точно есть определённый список команд. + события подключения/отключения.
    Банальный пример: com-порт , он может быть встроенный, через pci карточку и через usb. И сейчас нет никакой гарантии, что драйвер на конкретный порт будет поддерживать например смену скорости передачи не говоря уже про поиск всего этого. Сейчас есть звуковая подсистема, которая работает через драйвер sound , но звуковуха выбирается только первая попавшаяся и сменить её нельзя. а кроме этого sound ещё и "бд" звуковых карт загружает в память и эти данные там просто потом место занимают.
  • 2) В структуре каждой файловой системы есть мьютекс по имени "lock". Если переместить его в структуре FAT, то и адрес будет везде одинаковый. А других программ вроде как и нет.
  • да, вполне подходящий вариант, нужно добавить этот мьютекс в основную структуру и для работы с секторами раздела этого будет достаточно
  • Doczom wrote: Sun Aug 06, 2023 12:27 am 1) Из найденный проблем в дисковой подсистеме есть одна очень неприятная:
    подключённый iso образ может не инициализироваться, так как там может не оказаться mbr или gpt разметки.

    Сейчас эта проблема можно сказать не актуальна, так как ide atapi дисководы работают в обход основной дисковой системы, но при написании драйвера для монтирования образов и переписывании драйвера на iso9660 эта проблема очень актуальна.
    Кроме этого, для atapi дисков не хватает нескольких функций, например получения lba последней сессии записи, из за чего поддержка мультисессии в iso9660 и UDF может отсутствовать.

    Предложение по решению этой проблемы:
    Введение дополнительного поля типа устройства как у дисков, так и у драйверов файловых систем. Это позволит определить что за носитель(какие у него функции должны быть, как с ним работать) и отсеивать невозможные для конкретного носителя фс.
    A missing partition table shouldn't be an issue because a single partition covering the whole disk is then created. It works right now for usb drives, it should work for optical media.

    Regarding multisession, I don't think it's a priority right now. I haven't been using optical media at least for a decade. Does anybody complain KolibriOS doesn't support multisession? Let's assume for now that the very first session is enough.

    Doczom wrote: Sun Aug 06, 2023 12:27 am 2) Внедрения функций чтения/записи дисковых устройств:
    Для внедрения чтения/записи секторов диска/раздела для раздела должно существовать поле, блокирующее работу с разделом для драйверов фс, и других программ.
    You can just replace read, write and other callbacks of a partition to stub functions returning some error code.

    Also, I wouldn't recommend making the lock you've mentioned a required field because a read-only FS shouldn't have a global lock. The per partition lock is currently used to protect temporal information which should ideally be stored in a file structure pointed to by a file descriptor. So, again, our partition wide locks should go away eventually, not become a required field.
    Doczom wrote: Sun Aug 06, 2023 12:27 am 3) Использование состояния потока в обработке работы оконной подсистемы:
    Сейчас для перерисовки окна используется состояние потока, что добавляет неудобства в код(надо WDATA в APPTADA конвертить) и лишнюю привязку окон к потоку, что не очень то и хорошо. Как вариант решения, которое уже частично используется: расширение WDATA и перенос всех связанных с окнами полей из APPDATA в WDATA. Сейчас структура WDATA имеет размер 64 байта и её расширению препятствует только нахождение на статичном адресе буфера для cd дисков.
    Maybe we can move the array of WDATAs instead? If it's always accessed via its label, not a magic number, then we can be flexible here. Of course, the static CD buffer is a design issue that is to be resolved. What I mean is that extending WDATA doesn't really depends on the CD-related work.
    Doczom wrote: Sun Aug 06, 2023 12:27 am 4) Отсутствие подсистемы устройств:
    Её нет, совсем. Нужна хоть какая-то подсистема для хранения данных о всех устройствах, чтобы можно было посмотреть туда и увидеть что есть такой-то com-порт например и знать что у него точно есть определённый список команд. + события подключения/отключения.
    Банальный пример: com-порт , он может быть встроенный, через pci карточку и через usb. И сейчас нет никакой гарантии, что драйвер на конкретный порт будет поддерживать например смену скорости передачи не говоря уже про поиск всего этого. Сейчас есть звуковая подсистема, которая работает через драйвер sound , но звуковуха выбирается только первая попавшаяся и сменить её нельзя. а кроме этого sound ещё и "бд" звуковых карт загружает в память и эти данные там просто потом место занимают.
    These are two different things. The so called device subsystem won't fix automatically a driver that can't handle e.g. two sound cards or switch between them. That said, I agree that we need a unified way to announce new devices and lookup existing ones.
  • Who is online

    Users browsing this forum: Ahrefs [Bot] and 4 guests