Во-первых, для экономии памяти.
Во-вторых, при организации связанным списком перебор делать всё равно придётся, чтобы при выделении непрерывного блока страниц найти блок нужной длины. А освобождение памяти превратится в кошмар из-за того, что нужно будет просмотреть все блоки с целью проверить, не нужно ли склеить только что освобождённый с каким-то из старых.
Колибри для встроенных систем?
-
Ушёл к умным, знающим и культурным людям.
diamond, sorry. До памяти я еще пока не дошел
Это я в догонку к "bts" из event.inc
Там-то точно ничего сортировать нет необходимости
Т.е., совершенно конкретно, речь идет о init_events/alloc_event/free_event из kernel\trunk\gui\event.inc - ликвидация массива битов event_map напрочь, упростило бы дело
Мне представляется
Это я в догонку к "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) И вообще, как-то все это не очень доделано с ожиданиями... В смысле, не должно это правильно работать...
Конечно, у меня есть соображения, как довести конкретно это до "товарного вида". Эти соображения можно обсуждать, и они могут измениться, в результате-то. И можно довести до рабочего "причесанного" кода
Если все будет понятно с первой частью поста
Разбираясь в исходниках, наблюдаю следующее:
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. Потом можно модифицировать ядро.какие практические шаги должны быть с моей стороны
Никто не придумывал. Велик писал код, у него так по коду получилось - сначала проверка на то, что первое пришло в голову, а по коду первая проверка - самая приоритетная и т.д. Ну а с тех пор никто не менял, потому что всё и так работает. Аналогично с пунктом 2.1) Это кто же придумал делать рисование с самым верхним приоритетом приема события ??? Типа: пока все не нарисуешь - про наличие IRQ ничего и не узнаешь
2) Ну предположим (хотя правильным я это считаю с точностью до наоборот), и приоритеты приема событий соответствуют порядку битов в маске... И в чем тогда причина обратного порядка 6-го и 5-го битов ???
Ушёл к умным, знающим и культурным людям.
Хм.. а чего это оно со мной по аглицки разговаривает
Ну скажем так.... Если по крупному (на деталях типа, что принятие флага некого события и его последующий сброс - должны идти как 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-ов всего массива слотов (просто номерами этих слотов) один раз сделать надо будет, конечно же
Ну скажем так.... Если по крупному (на деталях типа, что принятие флага некого события и его последующий сброс - должны идти как 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 байт служат для передачи сообщения. В Колибри РЕ я набросал такую предварительную структуру.
Для TID имхо лучший вариант когда младший байт - номер слота и страшие три порядковый номер потока. Если считать с 1 после загрузки ядра будет 0x100 0x201 0x302 и т.д.
Забыл, слот 0 в Колибри не используется. Тогда если считать от 0 будет 0x001 0x102 0x203.
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;
Забыл, слот 0 в Колибри не используется. Тогда если считать от 0 будет 0x001 0x102 0x203.
Ну и ладненько. А лишний dword не сделает никакой погоды - на размере 512, kernel_alloc выделит ровно столько же памяти, 28КSerge wrote:А старший байт двойного слова зарезервирован для приоритета (sic!) события
Просто, если доводить это добро до ума, то надо и в 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
Можно и цикла не делать, как и в 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:
....
В общем, если у коллег не будет принципиальных возражений (основанных на более глубоком знании предмета), то я пока склоняюсь к "нахальным" альтернативам
Но предупредить-то я должен был
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 в макрос (в котором сегодня будет стоять вызов ф-ии поиска)
Что бы в будущем менять эту технику "легким движением руки"
Но мы же можем и не говорить
Можем даже предупредить: "пользоваться своими наблюдениями про младший байт TID-а Вы можете лишь на свой страх и риск, НО правильно будет использовать f18:21"
А что уж делает эта ф-ия; то ли младший байт берет, то ли 12 бит, то ли выделяет из этого TID только четные биты - не дело пользователя, и для него эта информация не более чем факультативная
Ну вот, с пользователем разобрались, и можем теперь со спокойной совестью использовать удобные для нас алгоритмы. Будет больше слотов - чего-нибудь да придумаем...
А может и еще раньше какая ни то гениальная идея посетит кого-нибудь
А для начала можно превратить pid_to_slot в макрос (в котором сегодня будет стоять вызов ф-ии поиска)
Что бы в будущем менять эту технику "легким движением руки"
А почему плохо ? Кто-то собирается запустить 10 000 потоков ?
Пусть будет 10 бит под номер слота. Всё равно выше крыши.
POSIX требует не меньше 8 потоков. Этот минимум выполняется.
Пусть будет 10 бит под номер слота. Всё равно выше крыши.
POSIX требует не меньше 8 потоков. Этот минимум выполняется.
Galkov
Некоторые вещи уже успел забыть. С EVENT.code планировалось так: старший байт класс события, потом приоритет, два младших байта код события. События реального времени получали класс 0хFF. Чем больше численное значение двойного слова тем важнее событие.
Некоторые вещи уже успел забыть. С EVENT.code планировалось так: старший байт класс события, потом приоритет, два младших байта код события. События реального времени получали класс 0хFF. Чем больше численное значение двойного слова тем важнее событие.
1) Ага , спасибо
2) Мне показалось, что diamond сказал "плохо" про такой сценарий:
а) мы открыли пользователю тайну про младший байт TID-а
б) пользователь стал это активно использовать
в) мы (по каким-то причинам) решили увеличить мак.число слотов - и получили проблему совместимости
г) получается, что мы сами себя "ограничили", а это плохо, ибо никому не дано знать, что день грядущий нам готовит
Помоему, так делать - надо, а открывать (в юридическом смысле) - не надо.
И не будет никакой проблемы (самоограничения)
2) Мне показалось, что diamond сказал "плохо" про такой сценарий:
а) мы открыли пользователю тайну про младший байт TID-а
б) пользователь стал это активно использовать
в) мы (по каким-то причинам) решили увеличить мак.число слотов - и получили проблему совместимости
г) получается, что мы сами себя "ограничили", а это плохо, ибо никому не дано знать, что день грядущий нам готовит
Помоему, так делать - надо, а открывать (в юридическом смысле) - не надо.
И не будет никакой проблемы (самоограничения)
Перед проведением коммита хотелось выяснить отношение коллег к некоторым чисто техническим вопросам:
1) Табуляторы и пробелы
В исходниках этих табуляторов выше крыше.
Сохранять их при редактировании исходников - крайне затруднительная задача.
Перестроишь редактор - замучаешься потом разбираться в своих же проектах
Мне показалось, что в кодах KoOS наиболее адекватен размер 8 для табулятора
Вряд ли это же будет адекватно для каких-нибудь ЯВУ...
В общем, пока так получается: поправил одну строчку в kernel.asm - и почти весь файл считается "правленным"
Правда в черепахе при включенном "Ignore all whitespaces" - смотрится все уже нормально
Дык вопрос такой: это нормально ли будет, если я внесу изменения с заменой всех табуляторов на пробелы
2) Кодировка
Порой не хватает языкового багажа для комментов
Вижу разные кодировки, а на чем бы договориться, в качестве внутреннего стандарта
Как бы я не вижу ничего плохого в 866-й, да перевести особых проблем не вызывает...
В нормальном текстовом редакторе
Беда только в том, что моя черепаха не признает таковой
Сделал я какую-ни-то очень полезную (предположим) правку, и сопроводил ее в sysfuncr.txt
Нажал commit - получаю список модифицировнных файлов
Дальше обязательно смотрю diff-ы (это уже на уровне рефлексов) - ну и облом на русском тексте
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 23 guests