Board.KolibriOS.org
http://board.kolibrios.org/

Колибри для встроенных систем?
http://board.kolibrios.org/viewtopic.php?f=25&t=1211
Page 7 of 13

Author:  diamond [ Sat Feb 21, 2009 6:13 pm ]
Post subject:  Re: Колибри для встроенных систем?

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

Author:  Galkov [ Sat Feb 21, 2009 6:17 pm ]
Post subject:  Re: Колибри для встроенных систем?

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

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

Author:  Serge [ Sun Feb 22, 2009 2:52 pm ]
Post subject:  Re: Колибри для встроенных систем?

Galkov

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

Author:  Galkov [ Sun Feb 22, 2009 5:34 pm ]
Post subject:  Re: Колибри для встроенных систем?

Наброски посмотрите :?:

Author:  Galkov [ Mon Mar 02, 2009 11:23 am ]
Post subject:  Re: Колибри для встроенных систем?

Народ, так все-таки....

Разбираясь в исходниках, наблюдаю следующее:
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) И вообще, как-то все это не очень доделано с ожиданиями... В смысле, не должно это правильно работать...

Конечно, у меня есть соображения, как довести конкретно это до "товарного вида". Эти соображения можно обсуждать, и они могут измениться, в результате-то. И можно довести до рабочего "причесанного" кода
Если все будет понятно с первой частью поста :)

Author:  diamond [ Wed Mar 04, 2009 12:32 am ]
Post subject:  Re: Колибри для встроенных систем?

Quote:
какие практические шаги должны быть с моей стороны

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

Никто не придумывал. Велик писал код, у него так по коду получилось - сначала проверка на то, что первое пришло в голову, а по коду первая проверка - самая приоритетная и т.д. Ну а с тех пор никто не менял, потому что всё и так работает. Аналогично с пунктом 2.

Author:  Galkov [ Wed Mar 04, 2009 1:58 am ]
Post subject:  Re: Колибри для встроенных систем?

Хм.. а чего это оно со мной по аглицки разговаривает :)

Ну скажем так.... Если по крупному (на деталях типа, что принятие флага некого события и его последующий сброс - должны идти как 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-ов всего массива слотов (просто номерами этих слотов) один раз сделать надо будет, конечно же

Author:  Serge [ Wed Mar 04, 2009 2:51 am ]
Post subject:  Re: Колибри для встроенных систем?

На самом деле размер EVENT.code 24 бита. А старший байт двойного слова зарезервирован для приоритета (sic!) события. Следующие 20 байт служат для передачи сообщения. В Колибри РЕ я набросал такую предварительную структуру.

Code:
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.

Author:  Galkov [ Thu Mar 05, 2009 9:55 am ]
Post subject:  Re: Колибри для встроенных систем?

Serge wrote:
А старший байт двойного слова зарезервирован для приоритета (sic!) события

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

А код, эту информацию возвращающий, мог бы выглядеть так:
Code:
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:
.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:
.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:
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
Но предупредить-то я должен был :)

Author:  diamond [ Thu Mar 05, 2009 11:34 am ]
Post subject:  Re: Колибри для встроенных систем?

Вообще идентификатор и слот потока - вещи, видимые на уровне API ядра для приложений, а жёстко прописывать на уровне API, что может быть не больше 255 одновременно запущенных приложений, нехорошо.

Author:  Galkov [ Thu Mar 05, 2009 8:02 pm ]
Post subject:  Re: Колибри для встроенных систем?

Если я правильно понял мысль, тогда ДА: говорить пользователю (прикладному программисту) как получить номер слота из TID - действительно плохо.

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

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

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

Author:  Serge [ Thu Mar 05, 2009 9:01 pm ]
Post subject:  Re: Колибри для встроенных систем?

А почему плохо ? Кто-то собирается запустить 10 000 потоков ?

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

Author:  Serge [ Thu Mar 05, 2009 9:18 pm ]
Post subject:  Re: Колибри для встроенных систем?

Galkov

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

Author:  Galkov [ Thu Mar 05, 2009 10:50 pm ]
Post subject:  Re: Колибри для встроенных систем?

1) Ага , спасибо

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

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

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

Author:  Galkov [ Sat Mar 28, 2009 4:33 pm ]
Post subject:  Re: Колибри для встроенных систем?

Перед проведением коммита хотелось выяснить отношение коллег к некоторым чисто техническим вопросам:

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

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

Page 7 of 13 All times are UTC+03:00
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/