Колибри для встроенных систем?

Using Kolibri in embedded systems
  • diamond, sorry. До памяти я еще пока не дошел
    Это я в догонку к "bts" из event.inc
    Там-то точно ничего сортировать нет необходимости

    Т.е., совершенно конкретно, речь идет о init_events/alloc_event/free_event из kernel\trunk\gui\event.inc - ликвидация массива битов event_map напрочь, упростило бы дело
    Мне представляется
  • Galkov

    Ты прав. Односвязный список здесь будет лучшим вариантом.
  • Наброски посмотрите :?:
  • Народ, так все-таки....

    Разбираясь в исходниках, наблюдаю следующее:
    1) Довольно много такого "добра", которое можно исправлять прямо "с листа" - не запутаться в 2-3-х командах не есть проблема
    2) Суета на форуме по любому (а из не мало) такому поводу, это трудозатраты на порядок большие, такового фиксинга
    3) Если до "последней буквы" - то shed и event мне сегодня понятны абсолютно
    4) И не очень веселые мысли все это вызывает (а в некоторых местах - и просто удивление)

    Так в чем вопрос-то.... Какое практическое продолжение может иметь знаменитая фраза: "ну сделай сам, посмотрим" :?:
    Да, я готов причесать, скажем, event (здесь моя готовность максимальна) по полной программе, с необходимым выходом на другие файлы
    Если, конечно, предварительно обсудить некоторые вопросы постановочного характера
    Конкретно: какие практические шаги должны быть с моей стороны :?:
    Естественно, начинаться должно с того, что на моем компе все работает - тут и обсуждать нечего
    А дальше-то - это должно быть гораздо более широкое тестирование... Может и многолетнее.



    А вот про "обсуждать" конкретно про event, то очень сильно меня интересуют следующие вопросы (это для затравки):
    1) Это кто же придумал делать рисование с самым верхним приоритетом приема события ??? Типа: пока все не нарисуешь - про наличие IRQ ничего и не узнаешь
    2) Ну предположим (хотя правильным я это считаю с точностью до наоборот), и приоритеты приема событий соответствуют порядку битов в маске... И в чем тогда причина обратного порядка 6-го и 5-го битов ???
    3) Вот те раз... Оказывается можно получить 0 по 11-й ф-ии, и даже при наличие не пустых событий в слоте. Впрочем, и в 10/23-й - спящие циклы задуматься заставляют...
    4) Про event-ы... Не всегда прерывания закрываются корректно, теоретически, можно просто тупо потерять события навсегда.
    5) Про формат поля EVENT.code - не очень понятно.. Разъяснения нужны - видно же (какие-то биты сбрасываются), что какой-то формат предполагался
    6) В чем великий смысл констант 512 (макс. кол-в событий в системе), 32 - размер очереди событий в приложении, да и сам размер поля EVENT.code - 24 байта...
    7) И вообще, как-то все это не очень доделано с ожиданиями... В смысле, не должно это правильно работать...

    Конечно, у меня есть соображения, как довести конкретно это до "товарного вида". Эти соображения можно обсуждать, и они могут измениться, в результате-то. И можно довести до рабочего "причесанного" кода
    Если все будет понятно с первой частью поста :)
  • какие практические шаги должны быть с моей стороны
    Запросить svn-аккаунт через http://kolibrios.org:3000/i-want-svn и разобраться с использованием svn. Потом можно модифицировать ядро.
    1) Это кто же придумал делать рисование с самым верхним приоритетом приема события ??? Типа: пока все не нарисуешь - про наличие IRQ ничего и не узнаешь
    2) Ну предположим (хотя правильным я это считаю с точностью до наоборот), и приоритеты приема событий соответствуют порядку битов в маске... И в чем тогда причина обратного порядка 6-го и 5-го битов ???
    Никто не придумывал. Велик писал код, у него так по коду получилось - сначала проверка на то, что первое пришло в голову, а по коду первая проверка - самая приоритетная и т.д. Ну а с тех пор никто не менял, потому что всё и так работает. Аналогично с пунктом 2.
    Ушёл к умным, знающим и культурным людям.
  • Хм.. а чего это оно со мной по аглицки разговаривает :)

    Ну скажем так.... Если по крупному (на деталях типа, что принятие флага некого события и его последующий сброс - должны идти как interlocked, останавливаться не буду)
    1) Пока мои соображения заключаются в том, что бы сменить порядок возврата событий на противоположный (правда IRQ тоже было бы логично расположить в порядке их физических приоритетов) - с 31 бита до нулевого.
    Тут нужна эрудиция коллег - насколько это мероприятие может быть опасно в плане совместимости
    2) Сделать новую ф-ю (ф-и) возвращающую все активные флаги событий сразу (может под персональную маску), чтобы у программиста появилась возможность выбирать порядок обработки.
    3) Таки починить "32-х битное преполнение" в таймаутах. Принцип такой же как и в 5-й ф-ии - тут особого велосипеда и не изобретешь
    4) Сделать так, чтобы ожидание event-ов все-таки правильно работало. Тут, правда, есть альтернативы.... Две, как минимум
    Надо подождать коментариев Serge - по логам, вроде это он все это добро про event-ы добавлял. И у него была какая-то генеральная мысль
    5) Ну и естественно - убрать битовый массив event_map


    Есть еще мысль, что флаги событий IRQ, определяемые неулевыми счетчиками прочитанного - далеко не самое умное....
    Но, наверное, не все сразу... Тем более, что за этими мыслями цепляются сразу следующие...
    По хорошему, эти флаги должны взводиться прямо в прерываниях, в irqhandler.
    Факт прерывания - это одна история. А заказ на прочтение чего-то их каких-то портов, несмотря на всю полезность такого мероприятия - это совершенно другая история, все-таки
    Правда, для это придется применять магическое слово pid_to_slot в прерываних, а от этого аж скулы сводит :(
    Отсюда сразу же возникает вопрос (это типа - мимоходом): diamond, а чему противоречит такая хитрая генерация TID-в, чтобы его младший байт был в точности и всегда равен номеру слота :?:
    Чего там собственно хитрого-то...
    Не пользоваться неким глобальным счетчиком, а старое значение слота в 9-й позиции увеличивать на 256 (при создании нового потока), и всего делов...
    Не, ну предварительную инициализацию TID-ов всего массива слотов (просто номерами этих слотов) один раз сделать надо будет, конечно же
  • На самом деле размер EVENT.code 24 бита. А старший байт двойного слова зарезервирован для приоритета (sic!) события. Следующие 20 байт служат для передачи сообщения. В Колибри РЕ я набросал такую предварительную структуру.

    Code: Select all

    typedef struct __attribute__ ((packed))
    {
        u32_t code;
        union
        {
            struct                          /* window event    */
            {
                u32_t  win;                 /* window handle   */
                u32_t  val1;
                u32_t  val2;
                u16_t  x;                   /* cursor x        */
                u16_t  y;                   /* cursor y        */
                u32_t  unused;          
            };
    
            struct                          /* realtime io     */
            {
                u32_t  sender;              /* service handler */
                u32_t  stream;              /* io stream id, if present  */
                addr_t offset;
                size_t size;
            };
    
            struct                          /* ipc event       */
            {
                u32_t  sender;
                u32_t   io_code;
                addr_t *input;
                size_t  inp_size;
                addr_t *output;
                size_t  out_size;
            };
        }; 24 байта а не 20 как в Колибри
    }event_t;
    Для TID имхо лучший вариант когда младший байт - номер слота и страшие три порядковый номер потока. Если считать с 1 после загрузки ядра будет 0x100 0x201 0x302 и т.д.


    Забыл, слот 0 в Колибри не используется. Тогда если считать от 0 будет 0x001 0x102 0x203.
  • Serge wrote:А старший байт двойного слова зарезервирован для приоритета (sic!) события
    Ну и ладненько. А лишний dword не сделает никакой погоды - на размере 512, kernel_alloc выделит ровно столько же памяти, 28К
    Просто, если доводить это добро до ума, то надо и в sysfuncr.txt на 68:14 написать нечто, понятное программисту
    А как я его напишу, если сам еще не понял до конца :)
    Пока понял так, что первый dword, это некий код, определяющий содержание и смысл последующей информации
    Ну например так:

    Code: Select all

    ======================================================================
    ==================== Функция 68, подфункция 14 =======================
    ===== Ожидать получения сигнала, от других приложений/драйверов. =====
    ======================================================================
    Параметры:
      * eax = 68 - номер функции
      * ebx = 14 - номер подфункции
      * ecx = указатель на буфер для информации (28 байт)
    Возвращаемое значение:
      * буфер, на который указывает ecx, содержит следующую информацию:
        * +0: dword: идентификатор последующих данных драйвера (-1 - при таймауте)
        * +4: данные драйвера (24 байта), формат которых определяется первым dword-ом
    
    А код, эту информацию возвращающий, мог бы выглядеть так:

    Code: Select all

    align 4                                            ;; f68:14
    proc get_event_ex stdcall, p_ev:dword, timeout:dword
    ; ожидание любого события в очереди EventList
      ..............
               lea esi, [eax+EVENT.code]
               mov edi, [p_ev]                ;copy event data
               mov ecx, 7
               cld
               rep movsd
               mov [edi-25],cl
    Правильно понял :?:
    Кстати говоря, сегодня нарисована технология приема событий, как LIFO, может лучше будет FIFO (даром что-ли у нас список двунаправленный) :?:

    Следующий вопрос - магическая константа 32...
    Может ну ее нафиг, вместе с полем ev_count (альтернативное определение "пустой очереди" у нас и так есть) :?:
    Пока я к такому склоняюсь...
    Тем более, что такая проверка есть в send_event, но ее нет в raise_event
    Если шибко мало (512) событий для 256 слотов, то можно новую релокацию делать "на ходу" (при отсутствии массива event_map - это не проблема)

    Ну и наконец, самое главное, про то, что: * Текущая реализация во время ожидания требует довольно "тяжёлых" операций переключения контекста.
    Как у нас сегодня сделано:

    Code: Select all

    .switch:
               mov eax, [TASK_BASE]
               mov [eax+TASKDATA.state], byte 5
               call change_task
               jmp .wait
    
    Не будет такое нормально работать: появится к примеру "флаг рисования", и будем мы сидеть в этом цикле всю жизнь.
    Как я уже говорил, тут есть альтернативы....

    Первая, и типовая - не ставить слот в 5-ю позицию, а просто тупо ждать, как почти везде и делается в аналогичных ситуациях.

    Вторая альтернатива - открыть (сегодня закомментированную) в get_event_for_app обработку 10-бита, но добавить к этой обработке предварительную проверку TASKDATA.event_mask на этот же бит (как там везде и делается)
    Тогда это могло бы выглядеть примерно так

    Code: Select all

    .switch:
               mov eax, [TASK_BASE]
               mov ebx, EVENT_EXTENDED
               xchg ebx,[eax+TASKDATA.event_mask]
               mov [eax+TASKDATA.state], byte 5
               call change_task
               xchg ebx,[eax+TASKDATA.event_mask]
               jmp .wait
    
    Такой фокус работает в get_event_ex - наличие флага, это именно наше событие, и ничье больше.
    Можно и цикла не делать, как и в sys_waitforevent - это и было бы, видимо, "правильным ожиданием"
    НО, в wait_event этой "правильности" уже нету - флаг могут взвести и "не наши" event-ы

    Третья альтернатива - нахальная. Попытка разрешить этот вопрос для всех, и на все времена
    Векторизируем то, чего у нас сегодня называется get_event_for_app. И всякий, кто поимел смелость поставить слот в 5-ю позицию, должен будет позаботиться о правильности обработчика wait_Test, который вызывается из find_next_task, ДО довольно "тяжёлых" операций переключения контекста
    Ну, скажем, примерно так:

    Code: Select all

    find_next_task:
      .....
        mov   al, byte [edi+TASKDATA.state]
        test  al, al
        jz    .found
        cmp   al, 9
        je    .loop
        cmp   al, 5
        jb    .loop
        jne   .noevents
        mov   edx,SLOT_BASE
        mov   dh,bl
        call  [APPDATA.wait_Test + edx] ;это вместо call get_event_for_app
        test  eax, eax
        jnz   @f
        mov   ecx,[timer_ticks]
        sub   ecx, [APPDATA.wait_begin   + edx]
        cmp   ecx, [APPDATA.wait_timeout + edx]
        jbe   .loop
    @@:
        mov   [event_sched], eax
        mov   [edi+TASKDATA.state], byte 0
    .noevents:
    .found:
      ....
    Это пока только набросок...


    В общем, если у коллег не будет принципиальных возражений (основанных на более глубоком знании предмета), то я пока склоняюсь к "нахальным" альтернативам :D
    Но предупредить-то я должен был :)
    Last edited by Galkov on Thu Mar 05, 2009 8:07 pm, edited 2 times in total.
  • Вообще идентификатор и слот потока - вещи, видимые на уровне API ядра для приложений, а жёстко прописывать на уровне API, что может быть не больше 255 одновременно запущенных приложений, нехорошо.
    Ушёл к умным, знающим и культурным людям.
  • Если я правильно понял мысль, тогда ДА: говорить пользователю (прикладному программисту) как получить номер слота из TID - действительно плохо.

    Но мы же можем и не говорить :!:

    Можем даже предупредить: "пользоваться своими наблюдениями про младший байт TID-а Вы можете лишь на свой страх и риск, НО правильно будет использовать f18:21"
    А что уж делает эта ф-ия; то ли младший байт берет, то ли 12 бит, то ли выделяет из этого TID только четные биты - не дело пользователя, и для него эта информация не более чем факультативная

    Ну вот, с пользователем разобрались, и можем теперь со спокойной совестью использовать удобные для нас алгоритмы. Будет больше слотов - чего-нибудь да придумаем...
    А может и еще раньше какая ни то гениальная идея посетит кого-нибудь
    А для начала можно превратить pid_to_slot в макрос (в котором сегодня будет стоять вызов ф-ии поиска)
    Что бы в будущем менять эту технику "легким движением руки"
  • А почему плохо ? Кто-то собирается запустить 10 000 потоков ?

    Пусть будет 10 бит под номер слота. Всё равно выше крыши.
    POSIX требует не меньше 8 потоков. Этот минимум выполняется.
  • Galkov

    Некоторые вещи уже успел забыть. С EVENT.code планировалось так: старший байт класс события, потом приоритет, два младших байта код события. События реального времени получали класс 0хFF. Чем больше численное значение двойного слова тем важнее событие.
  • 1) Ага , спасибо

    2) Мне показалось, что diamond сказал "плохо" про такой сценарий:

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

    Помоему, так делать - надо, а открывать (в юридическом смысле) - не надо.
    И не будет никакой проблемы (самоограничения)
  • Перед проведением коммита хотелось выяснить отношение коллег к некоторым чисто техническим вопросам:

    1) Табуляторы и пробелы
    В исходниках этих табуляторов выше крыше.
    Сохранять их при редактировании исходников - крайне затруднительная задача.
    Перестроишь редактор - замучаешься потом разбираться в своих же проектах
    Мне показалось, что в кодах KoOS наиболее адекватен размер 8 для табулятора
    Вряд ли это же будет адекватно для каких-нибудь ЯВУ...
    В общем, пока так получается: поправил одну строчку в kernel.asm - и почти весь файл считается "правленным"
    Правда в черепахе при включенном "Ignore all whitespaces" - смотрится все уже нормально
    Дык вопрос такой: это нормально ли будет, если я внесу изменения с заменой всех табуляторов на пробелы :?:

    2) Кодировка
    Порой не хватает языкового багажа для комментов
    Вижу разные кодировки, а на чем бы договориться, в качестве внутреннего стандарта :?:
    Как бы я не вижу ничего плохого в 866-й, да перевести особых проблем не вызывает...
    В нормальном текстовом редакторе
    Беда только в том, что моя черепаха не признает таковой :(
    Сделал я какую-ни-то очень полезную (предположим) правку, и сопроводил ее в sysfuncr.txt
    Нажал commit - получаю список модифицировнных файлов
    Дальше обязательно смотрю diff-ы (это уже на уровне рефлексов) - ну и облом на русском тексте :(
  • Who is online

    Users browsing this forum: No registered users and 6 guests