Board.KolibriOS.org

timer --> scheduler

какой смысл в смене частоты, если ее обработка по факту останется той же самой, только треску от переключателя прибавится?

Треску говоришь?
viewtopic.php?f=38&t=1277&hilit=fplay&start=17
viewtopic.php?f=38&t=1277&hilit=fplay&start=280

Mario
Одного 1КГц таймера разумеется мало. Нужен и планировщик чтобы переключиться в нужный момент на требуемую задачу.

art_zh wrote:А всего делов-то: попросить ядро прогнать короткий кусок юзерского кода, перезапустить таймер и выйти из прерывания

И каким образом ядро это сделает без смены контекста если адресные пространства не совпадут ? Напоминает старый анекдот "и что только не придумают русские программисты, лишь бы не строить хорошие дороги писать драйверы"

Ну, русские программисты всякой фигней страдают, а ты еще не видел какой фигней татарские программисты страдают!

Serge wrote:Одного 1КГц таймера разумеется мало. Нужен и планировщик чтобы переключиться в нужный момент на требуемую задачу.

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

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

Mario
Плееру для начала и быстрый таймер сгодится. Потому что типичная ситуация: все потоки в состоянии ожидания и os_idle мирно спит на hlt, хотя кадр надо было вывести 0.005 секунды назад.

Хм, а я думал что когда все потоки спят (по 10 функции к примеру), а один не спит, то этому поросенку достается главная сисьска с молоком. Разве не так?

Mario
Скорее всего. Но плеер так не свинячит. Если потоку надо подождать, честно отдаёт управление ядру.

Тогда надо изобрести 68.1 с параметром "Вот тебе мой велик квант, но чтобы через 2 часа миллисекунды вернул".

вот так люди постепенно доходят до jiffies. А потом и до dynticks.
Я неслабо прифигел, когда узнал что в винде последнее только в Win8 появилось.

Serge wrote:

art_zh wrote:А всего делов-то: попросить ядро прогнать короткий кусок юзерского кода, перезапустить таймер и выйти из прерывания

И каким образом ядро это сделает без смены контекста если адресные пространства не совпадут ?

Легко: перемаппит страницу юзеркода на кернелспейс, и запомнит точку входа.

Напоминает старый анекдот "и что только не придумают русские программисты, лишь бы не строить хорошие дороги писать драйверы"

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

art_zh wrote:Легко: перемаппит страницу юзеркода на кернелспейс, и запомнит точку входа.

Вот тут "враг рода человеческого" и вылазит.
Или весь код должен быть позиционно-независимым или привязан к конкретному адресу, а страница должна быть расшарена на все адресные пространства. В итоге загрузка такого кода будет мало отличаться от загрузки драйвера. Даже адрес будет в кернелспейс. Вызвать функции ядра проблематично, линковки с ядром нет, а если есть, то нет разницы с PE или COFF.
Берём твою задачу - копирование пикселов из одного буфера в другой.
Оба буфера MMIO ? Значит должны быть замаплены в ядро и код должен иметь доступ к указателям. Код из юзерспейс такую операцию провести не может, значит нужен костыль в ядре и т.д. В итоге проще добавить весть код обработчика в ядро, как с клавиатурой, и не мучиться с костылями и хаками.

Serge
Не проще: юзерское окно должно отрисовываться приложением, а не ядром (это был бы полный изврат).
Кстати, а ты не путаешь Колибри с Линуксом - у нас уже давно "враг рода человеческого" в ядре прописался, можно удобно общаться с MMIO из юзерспейса.

А-ядро вообще кощунствует аки пусикатки - там железо может грузить данные прямо в буфер приложения, даже когда приложение спит - ядро только предоставило заинтересованным сторонам физ.адрес буфера - и отошло в сторонку.

Для полного торжества хардвера над здравым смыслом мещанской десктопной рутиной осталось только закинуть в кернеспейс код юзерского обработчика РВ-таймера.

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

Вот это будет реально аццкий отжиг.

art_zh wrote:можно удобно общаться с MMIO из юзерспейса

В сильно хакнутой/заточенной -А ветке ? Так о том и речь.

юзерское окно должно отрисовываться приложением

В ядре есть способ донести в юзерспейс прерывание, и не только, через систему событий.

art_zh wrote: ... то для второго - процесс переключения будет занимать в тысячи раз больше времени, чем сама задача. А всего делов-то: попросить ядро прогнать короткий кусок юзерского кода, перезапустить таймер и выйти из прерывания.
...

Во-первых, на мой взгляд, выражение "кусок юзерского кода" и "кусок кода в ring-3" - это несколько разные вещи;
во-вторых, автор явно писал в контексте проектирования (то есть не о том, что уже есть, а о том, что может быть было бы неплохо реализовать),
в-третьих, автор явно это писал для примера.

Лично я понял "кусок юзерского кода" в контексте драйвера Kolibri, а драйверы работают в ring-0. Поэтому последний спор для меня выглядит довольно странным... Или я что-то пропустил либо не знаю?

P.S. Пожалуйста простите, если я кого-то обидел

ring -3? А зачем в Колибри столь специфичная вещь (да и к тому же, только интеловская)?