Новая модель ядра

Kernel architecture questions
  • http://meos.sysbin.com/viewtopic.php?t=49
    Там упоминается некий "драйвер для ATi или nVidia". Так вот, когда я его писал, он был основан именно на открытых драйверах BeOS.
    Были и определённые результаты: http://mikedld.com/i/driver_line.png и http://mikedld.com/i/mgb_vesa20.gif и http://mikedld.com/i/driver02.png
    Исходники всё ещё есть у меня, если это кому-то интересно, но я всё ещё не вижу смысла продолжать разрабатывать этот драйвер, так как нормальной драйверной модели нет.
  • mike.dld
    Может разработать стандарт для видеодрайверов? Он не обязательно должен быть такой, как у аудио. Можно определиться какие функции должны быть, как передавать данные. каке регистрв должны сохраняться.
  • Serge
    А можно поподробнее, что именно входит в "kernel API"?
    Ушёл к умным, знающим и культурным людям.
  • Внутренние функции ядра pid_to_slot, calculatescreen, change_task. Они нигде не описаны.
  • Я заметил,что в DMA режиме сохранение файлов на жестком диске происходит с ошибками.Если размер файла несколько килобайт,то это не заметно.А попробуйте сохранит в ANIMAGE картинку или сохранить образ на диске,то файлы портятся(отдельные части файла неправильно записываются).

    Насчёт организации интерфейса с видеодрайвером без переписывания программ - я уже думал.Когда я высказал идею метода,то никто ничего не ответил.Толи непоняли меня,толи про себя покрутили у виска.

    Насчёт карточек ATI незнаю - у меня видеокарта от nvidia.

    Михаил(mike.dld),отсутствие драйверной модели - не повод отказаться от разработок видеодрайвера.Serge налаживает нормальную работу с драйверами,поэтому нормальная драйверная модель будет.
  • andrew_programmer
    Не повод, но тогда практически получается кашу из топора варить... (Я сказал своё мнение, майк думаю сам ответит :))
  • Когда будет нормальная драйверная модель,то почему бы и не разрабатывать ?
    Тогда уже никакого топора не будет.
  • Неее.. Топор то останется, но уже будет крупа и специи :)
  • Вот когда она будет - тогда и поработаем. А пока что не хочется тратить эффорты на постоянное внесение изменений в ядро.
  • mike.dld
    Драйвернай модель с потолка не свалится. А для видеодрайвера надо определиться какие функции должны быть, как передавать параметры, какие регистры сохранять. Тот способ вызовов, который используют аудиодрайверы больше подходит для вызовов из программ. А для вызовов из ядра он громоздок. Лучше сделать указатели на функции как предлагал andrew_programmer. Но какие функции должны быть и сколько?
  • Драйверная модель для видеодрайверов Колибри.

    Ввведение.

    Любой видеодрайвер должен поддерживать те графические функции,которые есть в ядре - это минимум.Плюс некоторые дополнительные ,которые будут доступны через специальную системную функцию.

    Идея драйверной модели.

    При загрузке системы происходит автодетект видеокарты.Если для видеокарты имеется родной драйвер,то он загружается.Иначе загружается VESA драйвер(обладающий минимумом необходимых функций).
    После загрузки,драйвер должен заполнить структуру длиной n байт.Каждый байт в структуре соответствует какой-то графической возможности.К примеру: 1 - рисование точки,2 - рисование линии и т.д.Если драйвер поддерживает соответствующую возможность,то он ставит в соответствующем поле структуры еденицу.
    Драйвер должен иметь n графических функций.Если какую-то графическую функцию он не поддерживает,то эта функция будет просто возвращаться ничего не делая( функция будет состоять из команды ret ).Указатели на эти n графических функций будут загружаться в массив(массив будет находиться в ядре) указателей на функции видеодрайвера.Причем должно быть строгое соответствие номеру графической функции в структуре и номеру графической функции в драйвере.Тоесть если 1 - это рисование точки,то эта же функция в драйвере должна рисовать точку.
    При обращении к соответствующей системной функции запрос на отрисовку будет перенаправляться к таблице указателей из которой выбирается нужная графическая функция и происходит её вызов.
    Для получения доступа к дополнительныи(помимо графического минимума) графическим возможностям драйвера должна быть выделена системная функция.При обращении к ней можно будет получить структуру,длиной n байт.Таким образом можно будет узнать какие графические возможности поддерживает видеокарта.А для вызова соответствующей функции необходимо передать её номер в структуре + указатель на данные для отправки/получения данных от функции.
    Длина структуры может увеличиваться с n до n+k байт.По мере того,как в новых моделях видеокарт появяться новые возможности.

    Идею поняли ? Если поняли,то высказывайтесь.Только не молчите.
  • Зачем такие сложности, не пойму? Если драйвера в формате ELF или другом человеческом, там есть таблицы экспорта. Ядро подгружает драйвер, указанный в файле настроек, и импортирует их него функции. Если какие-то импортировать не получается - об этом пишется в лог, получается - адрес функции записывается в таблицу самим ядром, в нужную позицию. Плюс я бы делал не байты, а биты для получения всего лишь нескольких двойных слов с информацией о возможностях драйвера.
    Вобщем, я подумаю надосуге, что и к чему.
  • Код для VESA лучше оставить в ядре. Внешние драйверы не смогут аппаратно реализовать все графические функции и придётся добавлять туда код из VESA драйвера.
    Байтовую структуру удобнее заменить на битовый массив и проверять флаги командами bt.
    Надо посчитать все графические функции в ядре и определится с передачей параметров. Лучше через стек, особенно если параметров много.
  • andrew_programmer wrote: Я заметил,что в DMA режиме сохранение файлов на жестком диске происходит с ошибками.Если размер файла несколько килобайт,то это не заметно.А попробуйте сохранит в ANIMAGE картинку или сохранить образ на диске,то файлы портятся(отдельные части файла неправильно записываются).
    58-я функция глючит на больших файлах, и DMA тут ни при чём. Перепиши animage на 70-ю функцию, и глюки исчезнут.
  • Who is online

    Users browsing this forum: No registered users and 34 guests