Board.KolibriOS.org

Official KolibriOS board
It is currently Fri Nov 15, 2019 12:51 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 182 posts ]  Go to page Previous 15 6 7 8 913 Next
Author Message
PostPosted: Sat Feb 21, 2009 6:13 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Во-первых, для экономии памяти.
Во-вторых, при организации связанным списком перебор делать всё равно придётся, чтобы при выделении непрерывного блока страниц найти блок нужной длины. А освобождение памяти превратится в кошмар из-за того, что нужно будет просмотреть все блоки с целью проверить, не нужно ли склеить только что освобождённый с каким-то из старых.

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
PostPosted: Sat Feb 21, 2009 6:17 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
diamond, sorry. До памяти я еще пока не дошел
Это я в догонку к "bts" из event.inc
Там-то точно ничего сортировать нет необходимости

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


Top
   
PostPosted: Sun Feb 22, 2009 2:52 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Galkov

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


Top
   
PostPosted: Sun Feb 22, 2009 5:34 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
Наброски посмотрите :?:


Top
   
PostPosted: Mon Mar 02, 2009 11:23 am 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
Народ, так все-таки....

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

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


Top
   
PostPosted: Wed Mar 04, 2009 12:32 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Quote:
какие практические шаги должны быть с моей стороны

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

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

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
PostPosted: Wed Mar 04, 2009 1:58 am 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
Хм.. а чего это оно со мной по аглицки разговаривает :)

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


Top
   
PostPosted: Wed Mar 04, 2009 2:51 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
На самом деле размер 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.


Top
   
PostPosted: Thu Mar 05, 2009 9:55 am 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
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
Но предупредить-то я должен был :)


Last edited by Galkov on Thu Mar 05, 2009 8:07 pm, edited 2 times in total.

Top
   
PostPosted: Thu Mar 05, 2009 11:34 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Вообще идентификатор и слот потока - вещи, видимые на уровне API ядра для приложений, а жёстко прописывать на уровне API, что может быть не больше 255 одновременно запущенных приложений, нехорошо.

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
PostPosted: Thu Mar 05, 2009 8:02 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
Если я правильно понял мысль, тогда ДА: говорить пользователю (прикладному программисту) как получить номер слота из TID - действительно плохо.

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

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

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


Top
   
PostPosted: Thu Mar 05, 2009 9:01 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
А почему плохо ? Кто-то собирается запустить 10 000 потоков ?

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


Top
   
PostPosted: Thu Mar 05, 2009 9:18 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Galkov

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


Top
   
PostPosted: Thu Mar 05, 2009 10:50 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
1) Ага , спасибо

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

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

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


Top
   
PostPosted: Sat Mar 28, 2009 4:33 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
Перед проведением коммита хотелось выяснить отношение коллег к некоторым чисто техническим вопросам:

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

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 182 posts ]  Go to page Previous 15 6 7 8 913 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited